Запретный плод GOTO сладок (версия для микроконтроллеров)!

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

Логика программы c goto спускает меня на уровень абстракции «инструкция». Я вынужден читать каждую инструкцию и пытаться понять, куда пойдет выполнение программы в следующей строке. Я не могу охватить взглядом весь метод, потому что он связан внутри себя миллионом безусловных переходов, передающих управление в самое неожиданное место.

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

Я согласен с тем, что бездумное раскидывание goto ведет к трудности чтения алгоритма.
Приведенная блок-схема условна — просто какой-то пример. Поэтому и имена там такие же :-)…

А как насчет примера из учебника:

if (a > 0) {goto inner};
... // команды
{
X ax = X(a);
... // команды
inner:
// Сюда произойдёт переход по goto
...
// По завершении всех команд блока компилятор вызовет
// деструктор ~X() для переменной ax.
}

А конструктор для этой переменной не вызывался ведь?
Мне всё равно кажется, что использование GOTO без сильной необходимости разрушает принципы структурного программирования, но в одном вы правы точно — нельзя просто вычёркивать этот оператор из языка.

Полностью поддерживаю, отказываться от GOTO из-за эстетических соображений — это маразм. И если при программировании под PC все эти костыли прокатывают без проблем, то в МК левые флаги и проверки в момент сожрут всю память и такты. Надо думать головой в каждом конкретном случае, фанатизм не рулит :)

З. Ы. Подписался на камменты и запасся попкорном :)

А в чём отличие версии для микроконтроллеров и версии для PC?

Ну куда же в микроконтроллерах без goto :)

/*
* For PIC18 devices the low interrupt vector is found at
* 00000018h. The following code will branch to the
* low_interrupt_service_routine function to handle
* interrupts that occur at the low vector.
*/

#pragma code low_vector=0x18
void interrupt_at_low_vector(void)
{
_asm GOTO low_isr _endasm
}

#pragma code /* return to the default code section */
#pragma interruptlow low_isr
void low_isr (void)
{
/*… */
}

Перепишем вариант с goto немного, XXX и YYY — какой-то код:

if (a)
{
A;
goto L3;
}
L1:
XXX;
if (b)
{
YYY;
L2:
B;
L3:
C;
goto L1;
}
else if (!c)
{
D;
goto L2;
}
E;

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

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

можно попробовать вывести критерии, «когда точно нельзя GOTO».

Самый простой и в принципе достаточный: не используем низкоуровневый язык — пишем без GOTO.

Но для этого нужно не смешивать рассуждения для высокоуровневых и низкоуровневых языков — к сожалению, в этом посте смешение наблюдается, хотя это два разных холивара: аргументы совсем разные, да и по низкоуровневому случаю специалистов гораздо меньше, смысла спорить нет (кроме "в интернете кто-то не прав"

Предлагаю явно разделить случаи высокоуровневого/низкоуровневого программирования, и поспорить отдельно для высокоуровневого, готов развернуто выступить против GOTO

Что за копипаста предыдущей статьи?

Для тех, кто следит за темой — я в конце статьи вставил плюсы и минусы использования goto. Если кто хочет добавить/исправить — пишите в ответы сюда

Надуманные примеры, которые Вы применяете в пользу goto, ИМХО не нужны, в реальной жизни такого не бывает.

То, что Вы пишете про for, do, switch, что это «банальный goto, если использовать break и return» — передергивание. Испортить можно все что угодно, даже самым хорошим инструментом. Выходы из цикла через break привязаны именно к этому циклу, поэтому логику выполнения отследить легче, в отличие от оператора goto, который имеет право перейти куда угодно.

goto стали нелюбить с тех пор, как появились функции и блоки (куски кода между begin end и {}) в программах. Пусть эти блоки мало отражают действительность (реальное выполнение ассемблерного кода), но зато именно с помощью этих блоков стало возможным применить метод «разделяй и властвуй», т. е. код стал наглядным, читабельным и понятным (по крайней мере в умелых руках можно его сделать таким). То есть, не применяя goto, можно быть уверенным, что внутри блока идет линейное выполнение нужного алгоритма. Если Вы начинаете в своих программах применять goto, то Вы потенциально теряете такое удобство. Умные люди не любят goto за то, что справедливо считают — выигрыш от его использования намного меньше вреда, который оператор goto может принести.

Реализация алгоритма, описанного в статье, без goto:

1. void l1()
2. {
3.  if (b) {
4.   l2();
5.   B();
6.   l3();
7.  }
8.  else if ( c ) {
9.   E();
10.  }
11.  else {
12.   D();
13.   l2();
14.  }
15. }
16. void l3()
17. {
18.  C();
19.  l1();
20. }
21. // Entry point.
22. if (a) {
23.  A();
24.  l3();
25. }
26. else {
27.  l1();
28. }

* This source code was highlighted with Source Code Highlighter.

А в целом согласен с автором.