Вывод номеров строк двумерного массива, содержащих только положительные числа
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.
Почитай Массивы в C++ на практике. Полезно.
Это можно понимать по разному: либо как "в строке присутствует хотя бы один положительный элемент«, либо как » все элементы строки положительны". Второй вариант интереснее. Но надо все-таки уточнить.
Внешний цикл — по номерам строк. Внутренний цикл — по строке (по одномерному массиву). Во внутреннем цикле анализируешь строку и устанавливаешь или сбрасываешь переменную-флаг (типа
bool
). По окончании цикла в зависимости от переменной-флага выводишь или не выводишь номер строки (т.е. текущее содержимое переменной-счетчика внешнего цикла).Фтьiкай, смотри, почти все готово, только не могу я правильно применить bool.. Не догоняю как(
Тут я встрял..
mychernenko, так
вы не заполните массив рандомными числами от a до b, т.к. выражение
a + rand() % b
переводится следующим образом: генерировать числа от a до a + (b — 1).Эту задачу предлагаю решить так:
А теперь программу можно переписать так:
wtf?
Почему сразу на свалку? :)
Croessmah, вы перед тем как куда-то посылать, объяснили бы причину по которой посылаете.
Чем идея посчитать количество чисел между a и b в цикле, хуже формулы
(b + 1) - a
?хотя бы производительностью и читабельностью, не?
С учетом замечаний Croessmah и наглядности отображения строк, перепишем программу так:
С учетом замечаний Croessmah и наглядности отображения строк, перепишем программу так:
Не работает предпросмотр :(
Можно мне тоже вставить свои пять копеек?
Доброе время суток форумчане!
Пожалуй и я вставлю свои пять копеек. :) Croessmah, затронул тему производительности.
Всегда лучше сделать один раз вычисление, чем повторять его в цикле на каждой итерации. Ваш участок кода, Фтьiкай, этому противоречит.
Лучше написать так
Сразу отвечу и beginner, почему лучше произвести сразу арифметическое вычисление по поиску количества элементов ряда, чем вычислять его в цикле.
Запустите две тестовые программы по поиску количества элементов между двумя числами.
Одна из них
вторая
и вы сами увидите производительность каждой из них.
К слову. gcc фрагмент
не смог оптимизировать, тогда как
превратился в
Я не стал вдаваться в столь тщательную оптимизацию )))
Но в принципе, полностью согласен.
Оптимизирующие компиляторы — это, с одной стороны, хорошо: программы быстрее работают и занимают меньше памяти. Но с другой стороны, появляется некая недетерминированность: заранее неизвестно сможет компилятор соптимизировать (читай, исправить недочёт кодера) некий фрагмент, или нет. А с третьей стороны, вера (слепая вера!) в оптимизирующий компилятор приводит к снижению мотивации к повышению уровня знаний и опыта кодера (типа: «написал говнокод — ерунда, компилятор соптимизирует»).
Отсюда вывод: на компилятор надейся, а сам не плошай. Что бы повысить качество конечного продукта, необходимо писать качественный код. Тогда компилятор с большей вероятностью сделает необходимые оптимизации. Вообще, по моему мнению, оптимизирующий компилятор предназначен для оптимизаций сгенерированного (самим компилятором!) машинного кода, а не для исправления ляпов кодера.