Вот пара кодов, интересуют флаги управления циклами




Короче суть: цикл контролируется флагом, или оператор условия контролируется, или ещё там что-нибудь, я всё никак не могу понять, как заранее придумать вот это, у меня получается написать правильно цикл только когда я начинаю его писать и по ходу дела там догоняю куда ставить флаг, чтобы всё работало как надо, но в результате вот из-за того что я заранее не могу этот вариант продумать у меня этот флаг то в начале оказывается то посередине, а я хочу ближе к концу его выносить или так его ставить как в этих примерах.
Если кто юзает такие флаги, где вы про них узнали ?
Чтоб типа научиться их заранее понимать а потом уже писать, а не наоборот.

inside_pointer, пользуйся "С++:код". Вопрос не понял...

не надо понимать флаги, надо понимать суть алгоритма и записывать его так чтоб было удобно.

Вот эти места


Так понимать суть алгоритма можно по-разному, как это поможет расставить флаги в нужных местах(мне или вначале или в конце или в середине, но так чтобы было понятно для чего он там).
А то просто ставить флаг от которого "что-то" зависит - это не то.

Подсветку ставить не буду.

ты зациклился на флагах.. они совсем не главные.. пиши так чтоб было легко понять и тебе и другим и можно совсем без флагов ))

Да мне нужен этот навык, где-то ж такое объясняют, а если объясняют откуда-то читают.

А из-за этих флажков программа компактнее и понятнее(только если они правильно стоят, когда видно для чего они и как они управляют условием цикла или ветвления)

Если такой навык помогает сделать программу чётче и понятнее, я буду продолжать его искать.

по моему, программа понятнее, когда флагов нету вообще. и, имху, лучше от флагов избавляться, если есть возможность.
использование флагов диктуется алгоритмом и, соответственно, расположение их зависит от алгоритма.
использование флагов, позволяет избавиться от повторяющегося кода.

первый вариант можно записать так:


здесь каждое состояние оригинального цикла рассматривается своим под-циклом.
+ такой код читать проще (особенно если каждое состоянию выделить в отдельную функцию)
+ такой код работает быстрее (т.к. на каждое состояние свое количество проверок)
- увеличен размер код

оригинальный вариант есть смысл использовать, когда необходимо сократить размер кода.
этот вариант есть смысл использовать, когда необходимо сократить время выполнения.

в обычных ситуациях (в 99.9% случаев) нету необходимости ни в одном, ни в другом.
необходимось определяется в момент тестирования, т.к. зарание не известно, что именно этот кусок кода самый большой или самый медленный. поэтому использовать надо вариант, который первым был написан и работает, и не заморачиваться по этому поводу.
самый дорогой ресурс - время, потраченное на разработку. если алгоритм работает, то мы его используем до тех пор, пока не выяснится необходимость в его доработки.

перевод из оригинала в этот вариант, осуществляется расписыванием каждого состояния.
перевод из этого варианта в оригинал, осуществляется выявлением состояний (под-циклов) и привод к одному циклу. - в наше время смысла, имху, вообще не имеет, т.к. время выполнения дороже размеру кода.

можно расписать так:

такой вариант читать, имху, еще проще.
он дает возможность повторного использования кода в других местах программы (выделенные функции).

вывод:
вариантов записать один и тот же алгоритм много. если есть алгоритм, и он работает, не надо заморачиваться по поводу его улучшения пока не назреет такая необходимость.
мое имху - из 3-х вариантов, самый лучший последний, т.к. есть возможность повторно использовать код. но если в программе эти функции использоваться не будут, то этот вариант будет хуже первых двух, т.к. необходимо было потратить время, чтобы выделить функции.
из первого и второго варианта, лучше тот, который был написан первым.


Это сообщение отредактировал(а) korian - 25.3.2008, 08:27

обожемой. Я в этих флагах всегда путаюсь. Потому мне чаще всего удобнее поставить 

Тут флаги помогают контролировать циклы и они универсальны для любого языка.
+ флаг гибче break или continue, потому что может принимать разные значения

Это вроде такого goto реализованного внутри ветви алгоритма, только флаг по-другому зависит от кода, поэтому таких накладок как с goto не будет.

Ну типа границы для программы, чтобы она не могла пройти куда-нибудь, только память не жрёт.


Типа распределённый вариант, у меня я не знаю почему когда всё в одном работает гораздо быстрее, когда разношу работает медленнее, имею ввиду другие коды, которые больше и которые тоже можно разносить а можно сносить.

Вижу минус такого кода в том, что если что-то надо будет поменять, надо будет лазить по всему коду, чтобы ничо случайно не осталось. Код побольше и писец ресурсу - времени.


Но он сделан для цпп, а надо универсальный.

Всё равно спасибо за идеи разные подходы к одной и той же реализации это интересно, флаги то тоже разные бывают, бывают такие в которых через месяц ничо неясно, бывают жёстко вшитые в код, что если менять то всё, а бывают вот такие как в пузырьковой сортировке, мало памяти (char) что делает ясно на раз два и главное не мешается, если всегда такой флаг юзать, во всех программах, он просто станет необходим в итоге.

Некоторые goto внутри функций юзают, я как-то не очень к этому.


Флаг работает и в while и в for и в if и в switch одинаково, а эта штука везде по-разному да и не везде есть, не только касаемо операторов, а ещё и языков программирования   

он вообщем-то и есть универсальный, а точнее легко дорабатываемый.
понадобилась возможность чтения не только из cin, переписываем одну функцию и все.


в уже написанном коде ничего менять не нужно.



ну вообще странно... а медленее и в релизе тоже? а inline используете?


кода то больше, но сложность восприятия меньше, и не известно что будет быстрее.

я не говорю, что флаги нет смысла использовать, просто об этом задумываться не надо, пока оно не стукнет по голове и скажит доработай тут.

'Вот это' называется конечный автомат (он же state machine). Флаг (который state) на самом деле хранит состояние автомата. По теории и реализации таких автоматов есть куча литературы - ищи и читай   

Машинисцизм - болезнь, когда пациент прибывает в непоколебимой уверенности, что задача, которую он не может не только решить, но даже и внятно сформулировать, будет немедленно решена, как только он сядет за компьютер.   
Читайте книги - они rulezz   
О! Никогда не пробовал писать программы не думая, надо попробовать - вдруг получится   
Алгоритм обычно придумывают ДО того, как начинают писать.

оффтоп


хехе, xvr, ты живешь в идеальном мире 

Это сообщение отредактировал(а) Alek86 - 25.3.2008, 13:24

  
Да нет, во вполне реальном мире. И я обычно представляю, что собираюсь писать ДО того, как начинаю собственно писать. Конечно не во всех подробностях, но в общем и целом представляю. И если в процессе написания у меня возникают вопросы 'куда и какой флаг поставить', то я беру бумагу и ручку и разбираюсь с этим на бумаге, и только потом возвращаюсь к компьютеру.
И могу сказать, что за все время, что я програмирую (~20 лет) меня этот подход еще ни разу не подводил.   

Ок


До inline ещё не дошёл
Короче морской бой консольный рисует символы и кнопки сканирует быстрее когда всё в одном, когда вытаскиваю раскладываю получается медленнее.


Ну обычно так и бывает, когда надо что-то сформулировать и не получается, надо сесть за комп и в блокноте потихоньку догнать.
Для этого иногда надо код переписывать переписывать пока он не примет форму скелета хотя бы какого-то.

Добавлено через 3 минуты и 4 секунды

Я в блокноте разбираюсь.

inline в C нету

Это сообщение отредактировал(а) inside_pointer - 26.3.2008, 02:08

The specification for "inline" is section 6.7.4 of the C99 standard (ISO/IEC 9899:1999).

Ага, там просто прочитал у Герберта Шилдта в книжке что короче в C++ определены, запустил щас функцию с inline ошибок вроде не выдаёт.