Ага. Тогда вот что я скажу. Пусть есть такая реализация:

Цитата

int IsEnough= 0; for(int Pivo=20; ( !IsEnough ) && (Pivo>0); Pivo--) {   DrinkOnePivo(true);   for(int Vodka=20; Vodka>0; Vodka--)   {       DrinkOneVodka(true);       if ( !CanIAnswerMyNameGood() )       {          IsEnough= 1;          break;       }   } }

Но гораздо элегантнее написать так:

Цитата

for(int Pivo=20; Pivo>0; Pivo--) {   DrinkOnePivo(true);   for(int Vodka=20; Vodka>0; Vodka--)   {       DrinkOneVodka(true);       if ( !CanIAnswerMyNameGood() )          goto IsEnough;   } } IsEnough:

Это сообщение отредактировал(а) Chingachguk - 16.1.2004, 10:14

Chingachguk А если таких goto стоит куча и они посылают не только за пределы цикла,... Как такое читать?

Цитата

Ага. Тогда вот что я скажу. Пусть есть такая реализация: QUOTE  int IsEnough= 0; for(int Pivo=20; ( !IsEnough ) && (Pivo>0); Pivo--) {   DrinkOnePivo(true);   for(int Vodka=20; Vodka>0; Vodka--)   {       DrinkOneVodka(true);       if ( !CanIAnswerMyNameGood() )       {         IsEnough= 1;         break;       }   } } Но гораздо элегантнее написать так: QUOTE  for(int Pivo=20; Pivo>0; Pivo--) {   DrinkOnePivo(true);   for(int Vodka=20; Vodka>0; Vodka--)   {       DrinkOneVodka(true);       if ( !CanIAnswerMyNameGood() )         goto IsEnough;   } } IsEnough:

Я всегда делаю по первому примеру.

Не, если ГОТО много, то в программе разобраться нереально!

Chingachguk, плагиатор !!!

Цитата

for(int Pivo=20; ( !IsEnough ) && (Pivo>0); Pivo--) {   DrinkOnePivo(true);

да ладно нормальный оператор

Цитата

Chingachguk А если таких goto стоит куча и они посылают не только за пределы цикла,... Как такое читать?

и

Цитата

Не, если ГОТО много, то в программе разобраться нереально!

Ну так способов испортить код существует много ... Например, часто нажимая на insert+past... Фишка в том, что надо делать как лучше а не так, как учат профессора ;)

Всё равно наличие Goto говорит о непродумманости алгоритма. Пусть я напишу больше букв в коде, но через месяц я пойму, что имел в виду, просматривая этот кусок. С гоуту буду разбираться на порядок дольше.

December, согласен. В школе долго не понимал чем плохо использование goto. В какой-то книге по GWBASIC прочитал: "уровень профессионализма программиста уменьшается с каждым использованием в програме оператора goto", и там же теорему о том, что "любой алгоритм, в котором применяется оператор безусловного перехода можно переписать не используя данный оператор". Стало обидно, попробовал - интересно, но вроде ничего особенного. Потом еще несколько раз "заставил" себя не пользоваться GOTO и понял что это действительно так - без goto алгоритм выходит намного лучше, а последующие модификации проги выполняются почти безболезненно. Все равно как ООП и линейное программирование - в больших проектах для внесения изменений приходиться "разрушать и перепланировать" часть кода.

P.S. Бейсиком к тому моменту уже давно не пользовалься.

Имхо, это извращение. Запивать бутылку пива ящиком водки.
Я бы сделал так:

Код

for(int Vodka = 20; CanIAnswerMyNameGood() && Vodka > 0; Vodka--) {    DrinkOneVodka(true);    for(int Pivo = 20; CanIAnswerMyNameGood() && Pivo > 0; Pivo--)          DrinkOnePivo(true);   }

и не заморачивался бы ни с break'ом, ни с goto.

По поводу непродуманности и сопровождаемости.

Никто не грит, что нужно писать первое, что приходит в голову. Если посвятил достаточное количество усилий по разработке наилучшего варианта и в нем есть goto - оставть его. Если можешь написать
лучше без него - кто же спорит.

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

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

2. Опять-таки к вопросу о качестве кода. Удачное проектирование подразумевает, что каждый пишет свой модуль и потом все сопрягают свои усилия. Если модуль правило N человек, где N>10, то, скорее всего, в фирме какая-то фигня с текучкой кадров.

3. Понятие "читабельный код". Нет никаких четких правил по его написанию. Мне, к примеру, неудобно читать вложенные циклы, условия в них, опять циклы в условях и т.д. с многочисленными отступами. В результате тело самого внутреннего цикла начинается где-то с 50-ой позиции или еще далее. Отлично ! Никому не интересные проверки лежат рядом, а вот то, что интересно для анализа, нифига не видно. Но формально все правильно написано.

4. Из пункта 3 следует и 4: есть неудобство чтения goto, а вот мне намного неудобнее читать неоптимальный код. Если программер писал "лишь бы работало", то просматривать кучи чужих кодов вообще мрак. Обычно я такое удаляю и делаю заново. Но это гемор. Гораздо больший, нежели раз матернуться на чужой goto и ... все понять с первого раза.

5. Из пункта 4 следует и 5: реальность. Мы про что говорим ? Про реальные проекты или про "идеальные" ? Если про реальные, то везде, где я работал, я в той или иной мере видел все "достоинства", которые я перечислил в п.п. 3 и 4. Это неизбежный недостаток коммерческого программирования, когда надо "быстрее, а там видно будет". В той или иной степени такие вещи писали разные программеры и среди них были и неплохие. Но... никогда в реальной коммерции не будет отлажен код на таком уровне, что самым большим недостатком будет наличие goto в коде.

Ну а идеальные проекты пишутся на ... ассемблере ;) Потому, что иделаьные проекты не требуют переносимости - в идеальном проекте и машины одинаковые и архитектура - лучшие и не нужен си. Потому, что самый быстрый код и самый короткий код можно написать только на нем. Пример идеального проекта вы видели... в фильме "Терминатор" (1 часть). Код терминатора был написан на ассемблере ;) Ну а в ассемблере как бы нормально писать goto, просто там он именно в том виде, которым должен быть, а не в том, что реализован в языках HLL - условном.

Респект, Dov ! Ты единственный, кто попробовал улучшить мой пример без goto.

Цитата

Имхо, это извращение. Запивать бутылку пива ящиком водки.

Вообще-то обычно бывает именно так ;) Сначала "только по одной пива". Потом водки. Ну а потом нужно "залакировать" Вот тут-то и выполняется условие прерывания.

Цитата

Я бы сделал так:CODE  for(int Vodka = 20; CanIAnswerMyNameGood() && Vodka > 0; Vodka--) {    DrinkOneVodka(true);    for(int Pivo = 20; CanIAnswerMyNameGood() && Pivo > 0; Pivo--)         DrinkOnePivo(true);  } и не заморачивался бы ни с break'ом, ни с goto.

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

Это сообщение отредактировал(а) Chingachguk - 17.1.2004, 21:06

Я сейчас посмотрел, оказывается библиотека MFC во всю пользуется операторам goto.

Цитата

"уровень профессионализма программиста уменьшается с каждым использованием в програме оператора goto",

Похоже её писали ламеры.

Цитата

Я сейчас посмотрел, оказывается библиотека MFC во всю пользуется операторам goto. Похоже её писали ламеры.

У них там в основном везде одна метка (в конце функции), на которую идёт переход из разных точек функции -- типа такой глобальный Cleanup в конце функции, без которого не обойтись, и который если не выполнить (скажем, сделать "return FALSE" вместо "goto Cleanup") - выйдет некорректное действие. Например, когда выполняется очень сложная инициализация очень сложной структуры, с кучей сложных проверок и циклов - то любая ошибка при инициализации оставит кусок (ресурсы WinAPI, открытый файл, выделенную память и пр.), который нужно корректно вернуть системе. Имхо, всё это можно было бы реализовать и без goto, грамотно разделив каждый такой сложный процесс на подуровни (скажем, в виде отдельных функций).

Но. Нигде в MFC и речи нету о повсеместных "прыжках взад-вперёд-налево"!
То есть, M$ взращивает идею "мы против goto, но если без goto никак уже не обойтись (или сроки жмут) - тогда Ok, давайте вставим один-два оператора, но не более того".

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

Цитата(Chingachguk @ 17.1.2004, 21:03)

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

Chingachguk, ты не поверишь, но я предполагал, что рано или поздно встанет вопрос о скорости работы кода, хотя я, написав свой вариант, хотел показать, только, небольшую разницу в читабельности кода, так сказать, внешнее восприятие и не более того.
Просто, я (уж не знаю, почему) не люблю не только goto, но и break'и с continue'ями и, по мере возможности, стараюсь их обходить, не очень-то задумываясь об этой самой скорости.
Но, раз уж пошла такая тема, мне хотелось бы кое-что уточнить для себя.
Давай возьмём твой код и мой код и посмотрим, что же у нас, на самом деле, происходит.
Предположим, что CanIAnswerMyNameGood() изначально, т.е. до входа в первый цикл for равна FALSE.
Вот твой код:

Код

for(int Pivo = 20; Pivo > 0; Pivo--) {    DrinkOnePivo(true);    for(int Vodka = 20; Vodka > 0; Vodka--)    {        DrinkOneVodka(true);        if ( !CanIAnswerMyNameGood() )            goto IsEnough;    } } IsEnough:

Что же произойдёт дальше? Давай посмотрим(пока мы при памяти).
1. Проверяем, есть ли ещё у нас пиво - Pivo > 0. // ЕСТЬ
2. Пьём бутылочку - DrinkOnePivo(true). // хотя не должны этого делать, так как уже - FALSE
3. Проверяем, есть ли ещё у нас водка - Vodka > 0. // ЕСТЬ
4. Пьём бутылочку - DrinkOneVodka(true). // хотя не должны этого делать, так как уже - FALSE
5. Проверяем, а не FALSE ли у нас - if ( !CanIAnswerMyNameGood() ). // FALSE
6. И, только сейчас, выходим из цикла - goto IsEnough.

Вот мой код:

Код

for(int Vodka = 20; CanIAnswerMyNameGood() && Vodka > 0; Vodka--) {   DrinkOneVodka(true);   for(int Pivo = 20; CanIAnswerMyNameGood() && Pivo > 0; Pivo--)         DrinkOnePivo(true);   }

Посмотрим, что же здесь.
1. Проверяем - CanIAnswerMyNameGood() == TRUE ??? // нет, водку уже не проверяем, в цикл даже не заходим
Вопрос: почему ты считаешь, что твой код быстрее? Даже при условии, что он будет работать корректно.