Ответ на »сообщение 6053« (Илья Ермаков)
___________________________
В голове не помещается, зачем что клепать с break...
Вы знаете, когда (тогда) проходило обсуждение, я поиском в Дельфи поискал, где я сам использую break в циклах. С некоторым удивлением обнаружил, что у меня практически везде (если не исключительно, сейчас лень тщательно просматривать для уточнения) оно встречается именно в линейном поиске там, где заранее известны границы индексов элементов. Так что это тоже паттерн, который пишется почти на автомате. Забавно, что сегодня поискал по словам линейный поиск, linear search и из того, что нашел, в ряде мест код линейного поиска написан как раз через for. Например в английской википедии (пример на Jave):
http://en.wikipedia.org/wiki/Linear_search

Я лично согласен, что в данном случае
- цикл c while точно выражает смысл действий, тогда как с for - break есть некоторая неловкость выражения, как когда человек говорит что-то, понятно, что сказано, но сказано несколько странновато. Да, с этим я могу согласиться в результате обсуждения. Хотя здесь имхо можно по-разному трактовать смысл выражения с for.
- наверное да, инвариант проще отыскать в цикле с while, что может быть важным в  каких-то сложных ситуациях
- для единообразного подхода тогда уже имеет смысл писать все одинаково и в сложных и в простых циклах.

Не согласен с тем, что
- все части условия (как это правильно сказать?) всегда стоит перечислять в одном условии цикла. Мне бывает проще разбить условие на части (что-то - в условии цикла, что-то проверяется в теле цикла), так бывает легче сформулировать условие и легче не запутаться.

И цикл с for проще в том отношении, что не нужно самому изменять переменную цикла и что проверяется не отрицание условия (while ~condition do), а само условие (if condition then break) - на 1 умственную операцию меньше. :)

Интересно, что перевесит, когда в следующий раз мне придется писать строки с поиском? :)

Если вернуться к более общей теме, то разнообразнее у меня лично используется Exit из функции, когда есть набор нескольких условий и проверок.

А вообще спасибо за обсуждение, напомню, то моя первая реплика на эту тему была не "вот так нельзя" или "вот так надо", а "а почему так?" Пояснения я получил.

Ответ на »сообщение 6054« (user.ru)
___________________________

Ответ на »сообщение 6051« (Илья Ермаков)
___________________________
И как будет выглядеть приведенный пример с использованием дейкстровского цикла?

ядрёна вошь, извиняюсь :-)
ГДЕ ВЫ ПРИМЕР ВИДЕЛИ?
Пример - это задача, которую цикл должен решить (исходные предусловия и требуемые постусловия).
Была предложена готовая конструкция - схема цикла с проверками и break, но пустой "полезной нагрузкой". Задачи, для которой эта схема предполагалась, заявлено не было.

Это всё равно, что тут раньше предлагали схему:
for (...) {
...
if (...) {
...
break;
}
}
и утверждали, что её можно переписать только с лишним флагом:
while ( (...) && !stop )  {
...
if (...)
...
stop = true;
}

Стоит наполнить этот цикл конкретным содержанием (линейный поиск в произвольной последовательности), как выясняется, что и if-а-то никакого внутри не надо, а должен он быть снаружи, после цикла поиска, и что в условии ипользуются свойства сокращённого вычисления предикатов...
Так и здесь.
Кто сказал, что для решения невидимой из скелета задачи обязательно нужно три вложенных if-а, проверяющих три каких-то условия?

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

Ответ на »сообщение 6051« (Илья Ермаков)
___________________________

А "по Дейкстре" можно очень хорошо и такие циклы без break записывать, потому что дейкстровский цикл - многоветочный: WHILE cond1 DO ... ELSIF cond2 DO ... ELSIF cond3 DO .. END. Этакий "автомат", "щёлкающий" между ветками по условиям.

И как будет выглядеть приведенный пример с использованием дейкстровского цикла?

Ответ на »сообщение 6049« (Сергей Осколков)
___________________________

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
Действительно, понятия инварианта я не знал, но понятие инварианта - это всего навсего математический формализм, который можно применять, а можно и не применять при построении циклов. В огромном множестве ситуаций совершенно не обязательно применять этот формализм, для того, чтобы построить грамотный цикл.

Соврешенно верно. Потому что "огромное множество ситуаций" тривиально и сводится к комбинированию схем полного прохода, фильтрации и линейного поиска. Эти ситуации вообще уже перестают в мозгу воприниматься как самостоятельные циклы, а просто как стандартные кубики. В голове не помещается, зачем что клепать с break...
А по поводу понятия инварианта - знать его необходимо, потому что, не применяя его явно в обычных ситуациях (нафига из пушки-то по воробьям - Вы совершенно правы), всё равно в подсознании в фоне прокручивается обоснование кажду цикла... Уверенности гораздо больше.

Ответ на »сообщение 6049« (Сергей Осколков)
___________________________

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
Народ не знает базовых схем алгоритмики и понятия инварианта и суёт свои "велосипеды", пытаясь доказать, что без break никак.
Илья, не передергивайте. Во-первых, никто вам не доказывал, что без break никак нельзя. Вопрос был о том, почему вы считаете, что break нельзя использовать. Так что "никак нельзя" было с вашей стороны, а с стороны оппонентов было "почему нельзя и так".

Сергей, Вы не доказывали - в других ветках доказывали, потому что дискуссия эта возникает снова и снова :-) Доказывали, приводя алгоритмы самые тривиальные, из повседневной своей практики - а если в качестве примера необходимости чего-то приводишь свои повседневные "нужды", разве это не означает, что считаешь, что "без break жить нельзя"? Что программировать без break можно, естественно, понимают все, но вот что без него можно "жить" и уж тем более "хорошо жить" - оспаривают почти все.

Ответ на »сообщение 6048« (pepper)
___________________________

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
OK. В любом случае этот пример отражает определенный алгоритм. Перепишите этот алгоритм "правильно", хоть вообще без циклов, но чтобы он делал тоже самое. Вместо троеточий поставьте do_something1(), do_something2() и do_something3(). Или признайте, что как минимум этот конкретный алгоритм не может быть переписан "по Дейкстре" без потери читабельности.

Задачи-то нет - Вы даёте скелет от решения и просите его переделать! Какова задача - какое постусловие должен обеспечить цикл?

Да, я сам могу привести пример, когда цикл без явных выходов из середины будет громоздким - это обычно что-то подобное циклу обработки сообщений либо циклу работы парсера (хотя как раз для парсера пресловутый flag вполне уместен - т.е. он обычно выполняет функцию кода синт. ошибки)... Вы каждый день и даже каждую неделю пишете такие циклы? Обычно большинство циклов в программе - это трививальная схема типа линейного поиска, и беда, что программисты этих схем просто не знают, для них это каждый раз новая ситуация, на которую надо "клепать" новый цикл да с новыми break... А сложные циклы (типа "математических", сортировочных и т.п.) вообще строятся на инварианте (т.к. иначе нет никакой уверенности в их правильности), и там break не может возникнуть просто по способу построения цикла...

А если и пишете эти самые обработчики/парсеры, то уж не надо мешать цикл с условием и цикл с явным выходом - пишите while (true) {... break ... break ... } (в Обероне такой цикл LOOP ... EXIT ... EXIT ... END). А "по Дейкстре" можно очень хорошо и такие циклы без break записывать, потому что дейкстровский цикл - многоветочный: WHILE cond1 DO ... ELSIF cond2 DO ... ELSIF cond3 DO .. END. Этакий "автомат", "щёлкающий" между ветками по условиям.
Увы, ни один из известных языков этого цикла не поддерживает, кроме нового виртовского Оберон-07.

Ответ на »сообщение 6047« (Jack Of Shadows)
___________________________

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
Илья а как быть с pattern matching ?

А каким боком pattern matching к вопросу об императивных управляющих конструкциях? Есть он в мире ФП - и пусть себе есть, там свои законы - там вместо абстракции программы как преобразователя предикатов абстракция программы на основе лямбд.

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
Народ не знает базовых схем алгоритмики и понятия инварианта и суёт свои "велосипеды", пытаясь доказать, что без break никак.
Илья, не передергивайте. Во-первых, никто вам не доказывал, что без break никак нельзя. Вопрос был о том, почему вы считаете, что break нельзя использовать. Так что "никак нельзя" было с вашей стороны, а с стороны оппонентов было "почему нельзя и так".
Во-вторых, не стоит приписывать оппонентам все недостатки скопом. Это просто непорядочно. Например я - непрофессиональный программист (из ваших оппонентов). Действительно, понятия инварианта я не знал, но понятие инварианта - это всего навсего математический формализм, который можно применять, а можно и не применять при построении циклов. В огромном множестве ситуаций совершенно не обязательно применять этот формализм, для того, чтобы построить грамотный цикл. Что касается алгоритмов, м.б. экзамен я лично и не сдал бы, но вообще с классическими алгоритмами поиска, сортировки и т.д. я знаком и при необходимости по крайней мере загляну в книжку за деталями. В алгоритме линейного поиска, который привели вы, для меня не было ничего нового, предполагаю, что и для других участников обсуждения тоже.
Я же не припоминал вам, что вы сделали в примере поиска из нескольких строчек 2 ошибки и не доказывал на этом основании, что вы неграмотный программист. Не стоит и вам для утверждения своих позиций заниматься подобным.

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________


___________________________
Это - не пример!
Это схема уже построенного цикла. Дайте мне этот цикл с содержанием - в 95% он может быть перестроен по грамотным правилам без вложенных проверок.


OK. В любом случае этот пример отражает определенный алгоритм. Перепишите этот алгоритм "правильно", хоть вообще без циклов, но чтобы он делал тоже самое. Вместо троеточий поставьте do_something1(), do_something2() и do_something3(). Или признайте, что как минимум этот конкретный алгоритм не может быть переписан "по Дейкстре" без потери читабельности.

Ответ на »сообщение 6046« (Илья Ермаков)
___________________________
Илья а как быть с pattern matching ?
Ведь это и есть тот самый break в рекурсивных функциях.
Тоже обвините его в потере "потенциальной компактности рассуждений" ?
Но ведь это же абсурд.
Pattern matching и есть представление наиболее компактного и при этом ясного и читабельного предстваления алгоритма.

А break в ваших многочисленныз операторах цикла это и есть вынужденный костыль в языке, не предусматривающем pattern matching.