[skip]
VD>goto это единственный сто процентный выход из ситуации. Но выход это плохой. Лучше переделать условие циклов так, чтобы они учитывали такую ситуацию. Например:
[skip]
Никак не могу понять почему народ так боится goto? Для этого есть какие-то причины помимо эстетических? Ежели есть просветите плиз. А то я иногда пользуюсь, особенно в подобных случаях, и мне кажется это более красиво, чем с переменной...
ЗЫж Не флейма окаянного ради, может я и правда чего не знаю/понимаю?
А>>bool bContinue = true;
А>>while(bContinue) {
А>> for(int i = 0; i < 100; i++) {
А>> if (i == 77) {
А>> bContinue = false;
А>> break;
А>> }
А>> }
А>>}
А>>
LG>Я в общем то так и делаю, только подумалось, что можно по-другому...
!!!! Класс ! (Это относительно последнего Вашего замечания) Я долго смеялся, спасибо.
Есть мнение чайника.
1. По моему это работа для ассемблера. А именно для команды КУЕ, тьфу, RET. Правда, я это не проверял на интелах но на 580-м она работает следующим образом:
застваляет процессор взять адрес из стэка и продолжить выполнение программного кода с этого адреса. Если у интела RET работает аналогично, то возможно можно запомнить адрес внешнего цикла, перед выходом запихноть его в стэк (возможно даже насильно )
и вызвать RET.
Но, т.к. это мнение чайника, то возможно лучше GOTO (т.к. доказано, что неполное знание — ОПАСНО).
Желаю всем вдохновения.
Здравствуйте Patalog, Вы писали:
P>Никак не могу понять почему народ так боится goto? Для этого есть какие-то причины помимо эстетических? Ежели есть просветите плиз. А то я иногда пользуюсь, особенно в подобных случаях, и мне кажется это более красиво, чем с переменной...
Компиляторы иногда путаются с goto, и могут не правильно вызывать конструкторы\деструкторы.
Здравствуйте DarkGray, Вы писали:
DG>Компиляторы иногда путаются с goto, и могут не правильно вызывать конструкторы\деструкторы.
Предлагаешь ориентироваться на глючные компиляторы? На самом деле "выход из вложенного цикла" (не путать с "прыжком во вложенный цикл — классический пример, когда можно и даже нужно использовать goto. И прежде всего как раз из соображений наглядности, которую так портит goto в более других случаях.
P.S. А вот, может, кто скажет, насколько корректно "прыгать из цикла" наверх, т.е. до начала цикла? Я несколько лет назад с преподом на экзамене поспорил, и он меня не убедил (он утверждал, что это абсолютно некорректно, а вот прыгать "вниз" — типа можно).
Здравствуйте Patalog, Вы писали:
P>Никак не могу понять почему народ так боится goto? Для этого есть какие-то причины помимо эстетических?
С давних пор луди стали замечать, что если придерживаться некоторой стратегии, то дела идут лучше, а удача чаще приходит в их дом. В программировании одной из таких стратегий является структурное программирование.
P>Ежели есть просветите плиз. А то я иногда пользуюсь, особенно в подобных случаях, и мне кажется это более красиво, чем с переменной...
goto оператор неструктурного программирования. Стоит применить его один раз как захочется еще и еще... Читать такой код значительно сложнее. Научивщись же обходится без оного по прошествии некоторого времени начинаешь задаваться другим вопросом... Зачем нужен этот оператор?!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Vladik, Вы писали:
V>Здравствуйте DarkGray, Вы писали:
DG>>Компиляторы иногда путаются с goto, и могут не правильно вызывать конструкторы\деструкторы.
V>Предлагаешь ориентироваться на глючные компиляторы? На самом деле "выход из вложенного цикла" (не путать с "прыжком во вложенный цикл — классический пример, когда можно и даже нужно использовать goto. И прежде всего как раз из соображений наглядности, которую так портит goto в более других случаях.
На самом деле, наличие goto (даже в таких случаях) говорит о слабости проектирования (алгоритма) и не умелом использовании структурных возможностей языка. Всегда можно престроить код так, чтобы небыло операторов goto, циклов while(1) или for(;)... и при этом сделать код даже читабельней и проще. Так что в этой ситуации я бы для начала задался вопросом: а зачем нужен while(1)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>На самом деле, наличие goto (даже в таких случаях) говорит о слабости проектирования (алгоритма) и не умелом использовании структурных возможностей языка.
Ну зачем столько пафоса?
VD>Всегда можно престроить код так, чтобы небыло операторов goto, циклов while(1) или for(;)... и при этом сделать код даже читабельней и проще. Так что в этой ситуации я бы для начала задался вопросом: а зачем нужен while(1)?
while(1) — это лишь один из случаев (относительно сабжа) и туда действительно просится некий флажок. Конкретный пример я сейчас придумывать не стану, но несколько раз я сталкивался с такими ситуациями, где goto был бы очень даже в тему. Т.е. флажки и вынос в отдельную функцию были менее наглядны.
P.S. Лично я из принципа goto никогда не поставлю (просто рука не поднимется Но увидев чужой кусок кода именно с "таким" goto ничего плохого про написавшего его не подумаю.
Здравствуйте Vladik, Вы писали:
V>P.S. Лично я из принципа goto никогда не поставлю (просто рука не поднимется Но увидев чужой кусок кода именно с "таким" goto ничего плохого про написавшего его не подумаю.
Я знаю только одну ситуацию когда goto может быть оправданным. Это обработка ошибок без try/catch. Но более красиво (и главное безапасно) будет сделать для каждого типа ресурса класс-обертку и вообще избежать очистки.
Повторюь еще раз. goto не структурированный оператор. И его ипользование вност хаотичность в код. У нас в конторе написано ~ 300 000 рабочего кода (не считая кода к статьям) на C++ и goto не разу не применялся. Один программист как то раз начал отстаивать точку зрения "что в его случае лучше применить goto" и рьяно так... но когда мы переписали его код, он и сам согласился, что так элегантнее, понятее и безопаснее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
LG>while(1)
LG>{
LG> for(int i = 0; i < 100; i++)
LG> {
LG> if(i == 77)
LG> // вот тут хочу выйти вообще из всех циклов - из for и из while
LG> }
LG>}
LG>
LG>Как это сделать?
LeonGorbachev, у меня была похожая проблема, я использовал следующий код:
хотя лично я против гоуту ничего не имею, но если можно обойтись без него — так и делаю, и пока не было случая чтоб только вот гоуту и все, мож такой примерчик приведет хто? :) И ище, ПРОГРАММЕРЫ, зрите в ASM, посмотрите, как сделан любой цикл или условие в Вашей программе на ASM'е, ведь там стоит что-нить похожее:
test ecx,ecx
jne 00401d2b,
кто скажет что в ASM'е jne это не тоже, что и на С if(a!=b)goto c:;?
И еще, бороться за использование гоуту в программах бессмысленно, потому что этот страх перед гоуту мы всосали чуть ли не с молоком матери, вспомните любой учебник для начинающих, ведь там без конца долбят: хочешь стать крутым программером, забуть слово гоуту, крутые праграммеры никогда его не используют, потомучто не используют никогда.
Все. Извините, флейма я не хотел, просто прорвало.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Vladik, Вы писали:
V>>P.S. Лично я из принципа goto никогда не поставлю (просто рука не поднимется Но увидев чужой кусок кода именно с "таким" goto ничего плохого про написавшего его не подумаю.
VD>Я знаю только одну ситуацию когда goto может быть оправданным. Это обработка ошибок без try/catch. Но более красиво (и главное безапасно) будет сделать для каждого типа ресурса класс-обертку и вообще избежать очистки.
VD>Повторюь еще раз. goto не структурированный оператор. И его ипользование вност хаотичность в код. У нас в конторе написано ~ 300 000 рабочего кода (не считая кода к статьям) на C++ и goto не разу не применялся. Один программист как то раз начал отстаивать точку зрения "что в его случае лучше применить goto" и рьяно так... но когда мы переписали его код, он и сам согласился, что так элегантнее, понятее и безопаснее.
А по подробнее про "его случай" мона? Например кусочек его и вашего кода...
И каким образм вносит хаотичность (ежели конечно не ставить в каждой строчке)?
ЗЫж Еще раз повторюсь, какие причины _кроме_ чисто эстетических (может и неверное слово подобрал существуют для того чтобы не использовать goto?
Про то что он де не структурированный и т.д. я уже слышал, и не один раз.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Patalog, Вы писали:
P>>Никак не могу понять почему народ так боится goto? Для этого есть какие-то причины помимо эстетических?
VD>С давних пор луди стали замечать, что если придерживаться некоторой стратегии, то дела идут лучше, а удача чаще приходит в их дом. В программировании одной из таких стратегий является структурное программирование.
P>>Ежели есть просветите плиз. А то я иногда пользуюсь, особенно в подобных случаях, и мне кажется это более красиво, чем с переменной...
VD>goto оператор неструктурного программирования. Стоит применить его один раз как захочется еще и еще... Читать такой код значительно сложнее. Научивщись же обходится без оного по прошествии некоторого времени начинаешь задаваться другим вопросом... Зачем нужен этот оператор?!
Sorry читаю в нитевом режиме по этому сначало ответил на 29.05.02 03:21:39, а теперь только добрался до этого...
Хотя смысла это не меняет. Мне эта gotoфобия в плане структурного программирования сильно напоминает желание ООПшников все и вся превратить в объекты.
Мне кажется ето дело вкуса либо каких-то корпоративных правил\соображений. В первом случае — "De gustibus et coloribus non est disputandum" (с), во втором — "Против танка не попрешь" (с).
IMHO, ежели у кого-то возникают проблемы с чтением этого кода, енто личные проблемы этого кого-то. У меня это единственный случай, когда я использовал goto (к вопросу о "Стоит применить его один раз как захочется еще и еще"), и _мне_ это показалось более красивым решением, чем городить еще кучу циклов\функцый\сравнений\флагов.
ЗЫж Похоже все-таки тема вырождается во флейм.
ЗЗЫж 2DarkGray: В каких случаях и какие "Компиляторы иногда путаются с goto, и могут не правильно вызывать конструкторы\деструкторы."
Здравствуйте Patalog, Вы писали:
P>А по подробнее про "его случай" мона? Например кусочек его и вашего кода...
Это было в 97-ом. Так что теперь и не вспомнить.
P>И каким образм вносит хаотичность (ежели конечно не ставить в каждой строчке)?
В том, что он вносит не сруктурированную логику в логику программы. При этом правила чтения исходнико можно выбрасить на памойку, так как в любой строчке может ждать непредвидееное поведение. Причем если goto на кождом шагу, то на это рссчитываешь, а вот если это назаметно вставленный подарок, то мжно часми сидеть над чужим кодом не понимая почему он работает именно так. Кстаити, по тем же причинам не стоит применять кострукции типа:
if(a = b)
И предпочитать проверки в циклах отдельным if-ам.
P>ЗЫж Еще раз повторюсь, какие причины _кроме_ чисто эстетических (может и неверное слово подобрал существуют для того чтобы не использовать goto? P>Про то что он де не структурированный и т.д. я уже слышал, и не один раз.
Физических причин нет. Можно даже сделать ассемблерную всавку и осуществить дальний переход из любого места программы. Практика показывает, что обычно чем выше класс программиста тем реже реже в его коде можно встретить goto...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Такое решение позволяет читающему код легко понять принцип работы программы...
P>IMHO, ежели у кого-то возникают проблемы с чтением этого кода, енто личные проблемы этого кого-то.
Именно проблемы. Но не личные. Личные проблемы начинаются у программиста который пишит такой код... ну, когда он хочет устроиться на работу в контору где ему придется работать в команде.
P> У меня это единственный случай, когда я использовал goto (к вопросу о "Стоит применить его один раз как захочется еще и еще"), и _мне_ это показалось более красивым решением, чем городить еще кучу циклов\функцый\сравнений\флагов.
Тебе показалось.
P>ЗЫж Похоже все-таки тема вырождается во флейм.
А по-моему, многих начинающих она может остановить от привыкания к плохому стилю, так что она полезна. У нас же вроде личной неприязни не возникает?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
LG>while(1)
LG>{
LG> for(int i = 0; i < 100; i++)
LG> {
LG> if(i == 77)
LG> // вот тут хочу выйти вообще из всех циклов - из for и из while
LG> }
LG>}
LG>
LG>Как это сделать?
Ты наверно хотел услышать такой ответ как в PHP:
while(1)
{
for(int i = 0; i < 100; i++)
{
if(i == 77)
break 2;
}
}
Хм, ну раз пошла такая пьянка... Видимо все таки етот вопрос нужно прояснить до конца. Надеюсь господа модераторы все же не сочтут флеймом.
VD>Здравствуйте Patalog, Вы писали:
P>>А по подробнее про "его случай" мона? Например кусочек его и вашего кода...
VD>Это было в 97-ом. Так что теперь и не вспомнить.
P>>И каким образм вносит хаотичность (ежели конечно не ставить в каждой строчке)?
VD>В том, что он вносит не сруктурированную логику в логику программы. При этом правила чтения исходнико можно выбрасить на памойку, так как в любой >строчке может ждать непредвидееное поведение. Причем если goto на кождом шагу, то на это рссчитываешь, а вот если это назаметно вставленный подарок,
Тю, слово то какое страшное "не сруктурированную логику" И хде можно почитать "правила чтения исходнико"?
В чем непредвиденное поведение? В терминах эхотага ето видимо нечто совсем кошмарное
Видимо все таки нужно определиться с терминами. Что в твоем понимании "не структурированная логика"? А что "структурированная"?
>то мжно часми сидеть над чужим кодом не понимая почему он работает именно так. Кстаити, по тем же причинам не стоит применять кострукции типа: VD>if(a = b) VD>И предпочитать проверки в циклах отдельным if-ам.
Часами можно сидеть над исходниками линухового cdrtools (Ето я о наболевшем). Кстати goto я там не видел...
P>>ЗЫж Еще раз повторюсь, какие причины _кроме_ чисто эстетических (может и неверное слово подобрал существуют для того чтобы не использовать goto? P>>Про то что он де не структурированный и т.д. я уже слышал, и не один раз.
VD>Физических причин нет. Можно даже сделать ассемблерную всавку и осуществить дальний переход из любого места программы. Практика показывает, что обычно чем выше класс программиста тем реже реже в его коде можно встретить goto...
Практика показывает, что класс выше у того, у кого лучше работает прога (в смысле правильно работает и не подает). Про срок разработки пока скромно умолчим...
VD>Это типичное использование goto для организации цикла. Вот как можно переписать этот код:
Ну ежели типичное, так [с надеждой] может ничего страшного? А может ето в какой-нибудь паттерн оформить?
VD>for(;) VD>{ VD> for(SDirectoryRecord* pRecord3 = pRecord1->m_pFirstRecord; VD> pRecord3 != NULL; pRecord3 = pRecord3->m_pNextDirectory) VD> { VD> if(pRecord3 != pRecord2 && pRecord2->m_nLevel == pRecord3->m_nLevel) VD> { VD> nRes = CompareRecord(pRecord2, pRecord3, nType) == 0 VD> ? CCB_ERR_EQUAL_ID : CCB_ERR_NOERROR; VD> if(nRes != CCB_ERR_NOERROR) VD> { VD> pCheckControl->m_data1 = reinterpret_cast<long>(pRecord2); VD> pCheckControl->m_data2 = reinterpret_cast<long>(pRecord3); VD> //Передается юзеру, который должен как-то отреагировать на ошибку VD> nCallBackRes = pCheckControl->DoControl(nRes); VD> nErrorCount++; VD> VD> if(nCallBackRes == CCB_RES_MAKEAUTO || nCallBackRes == CCB_RES_IGNORE) VD> continue; //OK, продолжаем дальше VD> else if(nCallBackRes == CCB_RES_ABORT) VD> return nErrorCount; //Failed, отмена VD> else VD> //Юзер попытался исправить ошибку, надо проверить заново VD> break; VD> } VD> } VD>}
VD>Такое решение позволяет читающему код легко понять принцип работы программы...
У нас видимо разные понятия о легкости понятия принципов работы программы...
Кстати, или ето у меня проблемы, или в твоем ответе кусок кода выглядит менее красиво :) Это я о том что табы "съехали"...
P>>IMHO, ежели у кого-то возникают проблемы с чтением этого кода, енто личные проблемы этого кого-то.
VD>Именно проблемы. Но не личные. Личные проблемы начинаются у программиста который пишит такой код... ну, когда он хочет устроиться на работу в контору где ему придется работать в команде.
Тю, мы в разных командах работаем ;) У нас проблемы будут именно у "кого-то". Ибо таких не держим.
У тебя например возникли проблемы с пониманием? Там есть "неопределенное поведение"?
Вас это беспокоит? Вы хотите об этом поговорить? (Это я в НЛП тренируюсь. ;)
Кстати, у вас в команде какие требования к написанию\оформлению? (to All) Поделитесь. Ибо я конечно же погимаю, что с своим уставом, да в чужой монастырь... У меня по етой части опыта мало, работаю всего во 2-й конторе. Зато долго ;)
P>> У меня это единственный случай, когда я использовал goto (к вопросу о "Стоит применить его один раз как захочется еще и еще"), и _мне_ это показалось более красивым решением, чем городить еще кучу циклов\функцый\сравнений\флагов.
VD>Тебе показалось. :)
Ну вот, блин, пора креститься.
P>>ЗЫж Похоже все-таки тема вырождается во флейм.
VD>А по-моему, многих начинающих она может остановить от привыкания к плохому стилю, так что она полезна. У нас же вроде личной неприязни не возникает?
Их у нас пока нет :) Хотя насчет "плохому стилю" уже неплохое начало... :maniac:
Понятие стиль мне кажется пока нет. В смысле есть, но весьма эфемерное. Ибо у каждого свой. И многие умные дяденьки в умных книжках именно так и говорят: дескать упаси боже навязывать вам(читателям) мой стиль написания и т.д. :super:
Здравствуйте Patalog, Вы писали:
P>Практика показывает, что класс выше у того, у кого лучше работает прога (в смысле правильно работает и не подает). Про срок разработки пока скромно умолчим...
Да ну?! А как насчет сопровождения, поддержки, модификации и т.д. и т.п.? Не будем разводить флейм на тему — это банально и много раз поднималось здесь и не только здесь...
Здравствуйте The Lex, Вы писали:
TL>Здравствуйте Patalog, Вы писали:
P>>Практика показывает, что класс выше у того, у кого лучше работает прога (в смысле правильно работает и не подает). Про срок разработки пока скромно умолчим...
TL>Да ну?! А как насчет сопровождения, поддержки, модификации и т.д. и т.п.? Не будем разводить флейм на тему — это банально и много раз поднималось здесь и не только здесь...
Принеси песочку, родной... (с) Киндза-дза.
Не хочешь разводить флейм — не разводи. Тред плавно перешел на _стиль_ написания программ, что как заметил Vlad, может представлять определенный интере. А про класс начал не я, ежели ты вдруг не заметил.
Ежели прога кривая, ее конечно нужно сопровождать, поддерживать и модифицировать. Сие не означает, что хорошую прогу не надо сопровождать etc., это к тому, что при прочих равных, класс выше у того у кого работает, а не у того кто круче заплатки клепает.
Здравствуйте Patalog, Вы писали:
P>Здравствуйте The Lex, Вы писали:
TL>>Здравствуйте Patalog, Вы писали:
P>>>Практика показывает, что класс выше у того, у кого лучше работает прога (в смысле правильно работает и не подает). Про срок разработки пока скромно умолчим...
TL>>Да ну?! А как насчет сопровождения, поддержки, модификации и т.д. и т.п.? Не будем разводить флейм на тему — это банально и много раз поднималось здесь и не только здесь...
P>Принеси песочку, родной... (с) Киндза-дза.
Ку-у-у
P>Не хочешь разводить флейм — не разводи. Тред плавно перешел на _стиль_ написания программ, что как заметил Vlad, может представлять определенный интере. А про класс начал не я, ежели ты вдруг не заметил.
P>Ежели прога кривая, ее конечно нужно сопровождать, поддерживать и модифицировать. Сие не означает, что хорошую прогу не надо сопровождать etc., это к тому, что при прочих равных, класс выше у того у кого работает, а не у того кто круче заплатки клепает.
"Заплатки клепать" приходится в любом случае. И чем проще "клепать заплатки", тем лучше. Причем "клепать заплатки" не всегда приходится тому же, кто "хорошую прогу" писал.
Так что: обсудим, у кого же "класс выше"? Т.е. методы определения "высоты класса".
P>ЗЫж Жаль сдесь твита нет...