Запретный плод GOTO сладок!

Все хорошо в меру.
Когда знаешь где и как можно использовать goto без вреда — нет проблем.
А когда разбираешь программу где КАЖДЫЙ условный переход сделан с GOTO (Язык — С)?
if() goto P1;
else goto p2;

Спрашиваешь «Зачем?». А в ответ — я так привык… Когда сам изучал бейсик.
Вот из-за этого лично я против данного оператора.
Да, он иногда чрезвычайно удобен. Но это именно ИНОГДА.

А на мой взгляд goto это — зло. Его использование приводит к появлению ошибок. Сомневаюсь, что компилятор сможет оптимизировать код, напичканный goto.

Согласен, возможны редкие ситуации, когда он увеличивает читаемость. Единственный общий случай, когда я признаю оправданность его использования — выход из вложенного цикла. Собственно для этого в Java и модернизировали оператор break.

AFAIK, пространное эссе на тему «goto — зло» появилось в ту эпоху, когда по меткам можно было переходить не то что в циклы — в другие подпрограммы! Вот тогда — да, goto вносило огромную сложность. Сейчас же — если писать по человечески (небольшие функции, внятная нотация), то goto не внесет дополнительной сложности в понимание программы.

Вот здесь есть хороший пример грамотного применения goto: sim0nsays.livejournal.com/31460.html

Эта статья справедлива больше к С а не к С++. Ели мы говорим о С++ — то есть об ООП, то тут более актуальна как по мне вот эта статья — habrahabr.ru/blogs/cpp/112123/.

Проблема надумана. Я пишу программы с 1987 и как то обходился.

Меня вообще как то смущают темы «нужен ли goto» и «как написать пузырьковую сортировку» в 2011, на хабре, от людей с 20 летним стажем.

Кстати «более чем 20-летний стаж». Вы с 10 лет пишете?

Сonsidering goto harmfull is considered harmfull.

Goto нужен при обработке ошибок и выходе из вложенных циклах (хотя иногда лучше просто заранее подумать и минимализировать кол-во таких циклов). Про «выход в одном месте», если это не эмуляция try-catch, я не согласен: обычно можно всё общее свернуть в вызов функции-хелпера.

Автор молодец — разжигает холивар, ожидаю в топике появления многих точек зрения :-)

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

Для меня goto появился в 8м классе вместе с «Sinclair ZX Spectrum», доставшийся со склада школьного в качестве игрушки.
Уже тогда я понимал, что он (goto) иногда чрезвычайно удобен.
Потом был VB (10-11класс) но использовал его крайне редко. видимо специфика писания в том возрасте мелких оконных «программ» по сути процедурного программирования.

а сейчас вот Ностольджы нахлынуло

Единственное место где видел goto — драйвера. И то в очень маленьких дозах.
Обычно можно обойтись чем-нибудь вроде

do
{
    ...
    if(<error>)
    {
        ...
        break;
    }
    ...
} while (false);

Против goto ничего не имею, однако и не фанатею. Если переходить, то только вниз по коду.

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

Правило «goto-зло» имхо появилось не оттого, что оно действитльно зло, а потому, что в большой команде вместо того, чтобы каждому junior developer объяснять тонкости, проще его запретить и всем будет щастье

Мое мнение:
goto нужен для оптимизации в кое каких местах, это очевидно. Читаемости кода с моей точки зрения (как человек мыслящий критериями ООП) он не очень способствует.

Поэтому вывод:
1) Использовать goto в рамке сложной программы нельзя.
2) Использование goto выгодно когда требуется выполнить очень много однообразных операций, не выходящие за пределы одной процедуры, то есть в той процедуре где используется goto уже не должно вызываться других процедур.

Если вам кажется, что goto может улучшить код, то вы накосячили с архитектурой. В коротком коде еще можно изящно воспользоваться им, но если код достаточно сложен — ну его нафиг.

Что-то в последнее время большой приток алдековцев на Хабре :D

Хорошая статья!

В прекрасной книге Макконнела «Совершенный код» есть почти целая глава, посвященная goto. Там очень доступно раскрываются плюсы и минусы. Перескажу её в трех тезисах:

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

2. Оператор goto КАК ПРАВИЛО увеличивает сложность кода. Переход непойми-когда непойми-куда непойми-зачем.

3. В тех редких случаях, когда goto уменьшает сложность — его МОЖНО и НУЖНО использовать. Но нужно быть четко уверенным, что его применения оправдано.

Как и любой другой инструмент, goto бывает в тему, а бывает нет. Головой думать надо.

Сталкивался с доводкой под современные нужды программ написанных на старых реализациях fortran-а. Чёрт ногу сломит в старых конструкциях, когда использование GOTO было явным (кто видел, тот поймёт. Кто не видел — советую посмотреть занимательные / 15 do 21 сТЕЛО 21 GOTO 15 /).

Сейчас это (вредность) конечно не так актуальна, и я соглашусь с автором — подчас использовать GOTO проще и информативнее.

Использовать goto — это как переходить дорогу в неправильном месте. Вроде можно успеть, но шанс быть сбитым значительно выше.
Код функции, цикла можно свернуть и оставить короткий кометарий. Блок с goto как сворачивать непонятно. И не понятно, какой уровень сложности там в конце концов окажется. В конце коцов человек возьмет карандаш, бумагу и начнет чертить для себя схему работы этого goto коммутатора.
goto — игра в наперсток.
P.S. За статью все равно спасибо. Существует много догм в программировании, которые надо пересматривать.

В далекие 90-е моя учительница по Basic говорила что «чем больше операторов GOTO в программе тем ниже квалификация программиста».

В С++ ситуацию я не готов комментировать с достаточным основанием, но все же стоит сначала понять, что алгоритм должен делать и лишь потом переходить к его кодированию. Это вообще, общий совет. Сначала надо понять, что ты делаешь, а вот тогда и выяснится, что высокоуровневые примитивы лучше описывают задачу. Я не беру ситуацию низкоуровневой оптимизации, которая как понятно никогда не должна быть преждевременной.

В современных язык очень не любят goto из очень простых соображений, высокоуровневые примитивы предсказуемы. Точка входа в for, while, if предсказуема и понятна. Точка входа в for это строчка которая находится перед этим самым циклом. Да, внутри цикла переходы будут посложнее, но опять же и тут это предсказуемые и однотипные переходы. В случае с метками, никогда не поймешь откуда произошел переход на нее, пока не просмотришь ВЕСЬ код. Теряется свойство локальности, инкапсуляция кода.

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

Не понимаю весь вводный опус по поводу языка ассемблера. Если говорить честно, то кроме условных и безусловных переходов там вообще нет функций управления потоком выполнения (разве что call и retn). Никаких готовых циклов и if. Я к тому, что если кодить на асме, то использование jXX (прямого аналога goto/if+goto) — единственная возможность реализации условий и прочего.
А так да, если использовать goto умерено и не прыгать в центр блоков кода — то это может гораздо уменьшить объём кода, увеличить читаемость и как следствие уменьшить количество багов. Особенно часто goto хорош если в конце процедуры нужно выполнить несколько заключительных действий (закрыть файлы/освободить память) и только после этого выйти, а точек выхода из самого алгоритма несколько (примерно как в последнем примере). Можно использовать для этого exception'ы, но на мой взгляд такие извращения только для тех языков, в которых нет goto (например Python).

Пример изначально надуманный.

Как сказал один мой знакомый:
Автор нарисовал блок-схему с конкретными хомутами, и показал, что гоу ту применим в таких случаях. имхо, если в приложении дошли до таких изворотов в логике, то там уже пох на всё и можно писать все что угодно, goto тоже )

google и qt не используют исключения.
и?

и ничего.
просто одним инструмент подходит, другим нет.

также и с goto.

можно/нельзя — это не тот вопрос, который нужно задавать.

оправдано/не оправдано использование в каждом конкретном случае — вот это правильный вопрос.

char a, b, c;

for (a = 0; a < 10; ++a)
{
for (b = 0; b < a; ++b)
{
if (!c)
goto Leave;
}
for (b = 10; b < 15; ++b)
{
d ();
}
}

Leave:
e ();


а вот так разве не лучше?

void task()
{
char a, b, c;

for (a = 0; a < 10; ++a)
{
for (b = 0; b < a; ++b)
{
if (!c) return;
}
for (b = 10; b < 15; ++b)
{
d ();
}
}
}
...

task();
e ();


А теперь посмотрим на хитровывернутый алгоритм. Представление не имею что это за бред – но его надо реализовать.

Что значит «представления не имею, что это за бред»? А как же анализ ТЗ?