Чи коли-небудь вигідніше використовувати "goto" мовою, яка підтримує цикли та функції? Якщо так, то чому?

Я давно перебуваю під враженням, що gotoніколи не можна використовувати, якщо можливо. Днями переглядаючи libavcodec (який написаний на С), днями я помітив багаторазове використання цього. Чи коли-небудь вигідніше використовувати gotoмову, яка підтримує цикли та функції? Якщо так, то чому?

Є кілька причин використання заяви «goto», про яку я знаю (деякі з них уже говорили):

Чіткий вихід із функції

Часто у функції ви можете виділяти ресурси та потребувати виходу в декілька місць. Програмісти можуть спростити свій код, поставивши код очищення ресурсу в кінці функції, і всі "точки виходу" функції перейдуть на ярлик очищення. Таким чином, вам не потрібно писати код очищення в кожній "точці виходу" функції.

Вихід із вкладених циклів

Якщо ви знаходитесь у вкладеному циклі і вам потрібно вийти з усіх циклів, goto може зробити це набагато чистішим і простішим, ніж заяви про розрив та if-check.

Поліпшення продуктивності низького рівня

Це справедливо лише в перфрікритичному коді, але оператори goto виконують дуже швидко і можуть дати вам імпульс під час переміщення через функцію. Це, однак, меч з двома кінцями, оскільки компілятор, як правило, не може оптимізувати код, що містить gotos.

Зауважте, що у всіх цих прикладах готи обмежуються сферою дії однієї функції.

Кожен, хто є антицитатамиgoto , прямо чи опосередковано, статтю GoSo Edsger Dijkstra вважав шкідливою для обґрунтування своєї позиції. Старовинна стаття Dijkstra практично не має нічого спільного з тим, як gotoвикористовуються заяви сьогодні, і, отже, те, що йдеться у статті, мало що стосується сучасної сцени програмування. У goto-Менше мем узбіччях зараз на релігію, аж до його писаннях продиктовані високо, його первосвященики та уникнення (або гірше) сприймаються єретиків.

Давайте поставимо документ Діккстра в контекст, щоб пролити трохи світла на цю тему.

Коли Дайкстра писав свою працю, то популярні мови того часу були неструктурованими процедурними, такими як BASIC, FORTRAN (більш ранні діалекти) та різні мови складання. Досить часто люди, які використовують мови вищого рівня, перестрибують всю свою кодову базу у скручених, перекручених нитках виконання, що породило термін "код спагетті". Ви можете переконатися в цьому, перейшовши на класичну гру Trek, написану Майком Мейфілдом, і спробувати зрозуміти, як все працює. Знайдіть кілька моментів, щоб переглянути це.

ЦЕ "неприборкане використання твердження", що Дійкстра в 1968 р. Протидіяв у своїх роботах. ЦЕ середовище, в якому він жив, змусило його написати цей документ. Можливість стрибати куди завгодно у свій код у будь-який момент, який вам сподобався, це те, що він критикував і вимагав припинити. Порівнювати це з анемічними силами gotoна С або інших таких більш сучасних мовах просто піддається ризику.

Я вже чую піднесені співи культистів, коли вони стикаються з єретиками. "Але", вони скандують, "ви можете зробити код дуже важким для читання gotoв C." О так? Ви також можете зробити код дуже важким для читання goto. Як ця:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

Не gotoвидно, тому читати його треба легко, правда? А як щодо цього:

a[900];     b;c;d=1     ;e=1;f;     g;h;O;      main(k,
l)char*     *l;{g=      atoi(*      ++l);       for(k=
0;k*k<      g;b=k       ++>>1)      ;for(h=     0;h*h<=
g;++h);     --h;c=(     (h+=g>h     *(h+1))     -1)>>1;
while(d     <=g){       ++O;for     (f=0;f<     O&&d<=g
;++f)a[     b<<5|c]     =d++,b+=    e;for(      f=0;f<O
&&d<=g;     ++f)a[b     <<5|c]=     d++,c+=     e;e= -e
;}for(c     =0;c<h;     ++c){       for(b=0     ;b<k;++
b){if(b     <k/2)a[     b<<5|c]     ^=a[(k      -(b+1))
<<5|c]^=    a[b<<5      |c]^=a[     (k-(b+1     ))<<5|c]
;printf(    a[b<<5|c    ]?"%-4d"    :"    "     ,a[b<<5
|c]);}      putchar(    '\n');}}    /*Mike      Laman*/

Ні gotoтам. Тому він повинен бути читабельним.

Який сенс у цих прикладах? Це не мовні функції, які роблять нечитабельним, нездійсненним код. Це не синтаксис. Це погані програмісти. І погані програмісти, як ви бачите в цьому вище пункті, можуть зробити будь-яку функцію мови нечитабельною та непридатною. Як і forпетлі там. (Ви можете їх бачити, правда?)

Тепер, якщо справедливо, деякі мовні конструкції легше зловживати, ніж інші. Якщо ви програміст на C, я б придивився набагато уважніше до приблизно 50% застосувань #defineзадовго до того, як я б пішов на хрестовий похід проти goto!

Отже, для тих, хто намагався прочитати це далеко, є кілька ключових моментів, які слід зазначити.

1. Папери Дейкстрой на gotoзаявах були написана для середовища програмування , де gotoбуло багато потенційно більш руйнівною , ніж це відбувається в більшості сучасних мов, які не асемблер.
2. Автоматичне відкидання будь-яких цілей використання gotoчерез це є настільки ж раціональним, як і сказати: «Я намагався колись розважитися, але це не сподобалось, тепер я проти».
3. У gotoкоді є законним використання сучасних (анемічних) тверджень, які не можуть бути адекватно замінені іншими конструкціями.
4. Звичайно, є неправомірні використання одних і тих же тверджень.
5. Існують також нелегітимні способи використання сучасних контрольних висловлювань, таких як godoгидота, коли завжди помилковий doцикл виривається з використання breakзамість а goto. Вони часто гірші, ніж розумне використання goto.

Дотримуватися найкращих практик сліпо - це не найкраща практика. Ідея уникати gotoтверджень як основної форми управління потоком полягає у тому, щоб уникнути створення нечитабельного коду спагетті. Якщо їх використовувати в потрібних місцях, вони іноді можуть бути найпростішим, зрозумілим способом висловлення ідеї. Вальтер Брайт, творець компілятора Zortech C ++ та мови програмування D, використовує їх часто, але розумно. Навіть із gotoзаявами його код все ще ідеально читабельний.

Підсумок: уникати gotoзаради уникнення goto- безглуздо. Те, що ви дійсно хочете уникати, - це нечитати код. Якщо ваш goto-значний код читається, з цим нічого поганого немає.

Так як gotoміркування щодо програмного потоку важкі ¹ (він же "код спагетті"), gotoяк правило, використовується лише для компенсації відсутніх функцій: використання gotoфактично може бути прийнятним, але тільки якщо мова не пропонує більш структурованого варіанту отримання та сама мета. Візьмемо приклад Сумнів:

Правило з goto, яке ми використовуємо, полягає в тому, що для переходу вперед до однієї точки очищення виходу у функції переходить до goto.

Це правда - але лише якщо мова не дозволяє структурувати виключення з кодом очищення (наприклад, RAII або finally), що робить ту саму роботу краще (як це спеціально побудовано для цього), або коли є вагомі причини не використовувати структуровану обробку винятків (але у вас ніколи цього не буде, за винятком дуже низького рівня).

У більшості інших мов єдине прийнятне використання - gotoце вихід із вкладених циклів. І навіть там майже завжди краще піднімати зовнішню петлю на власний метод і використовувати returnзамість цього.

Крім цього, gotoце знак того, що недостатньо думок увійшло в конкретний фрагмент коду.

¹ Сучасні мови, які підтримують gotoреалізацію деяких обмежень (наприклад, gotoможуть не переходити на функції або виходити з них), але проблема принципово залишається тією ж.

До речі, те ж саме, звичайно, стосується й інших мовних особливостей, найбільш помітних винятків. І зазвичай існують суворі правила, щоб використовувати ці функції лише там, де зазначено, як правило, не використовувати винятки для контролю над винятковим потоком програми.

Ну, є одна річ, яка завжди гірша, ніж goto's; дивне використання інших операторів програмного забезпечення для уникнення переходу:

Приклади:

    // 1
    try{
      ...
      throw NoErrorException;
      ...
    } catch (const NoErrorException& noe){
      // This is the worst
    } 


    // 2
    do {
      ...break; 
      ...break;
    } while (false);


    // 3
    for(int i = 0;...) { 
      bool restartOuter = false;
      for (int j = 0;...) {
        if (...)
          restartOuter = true;
      if (restartOuter) {
        i = -1;
      }
    }

etc
etc

У C # операторі вимикання не допускається пропуск . Таким чином, goto використовується для передачі керування на конкретну мітку регістру комутатора або мітку за замовчуванням .

Наприклад:

switch(value)
{
  case 0:
    Console.Writeln("In case 0");
    goto case 1;
  case 1:
    Console.Writeln("In case 1");
    goto case 2;
  case 2:
    Console.Writeln("In case 2");
    goto default;
  default:
    Console.Writeln("In default");
    break;
}

Редагувати: Є одне виключення з правила "без пропуску". Прохідний доступ дозволений, якщо в заяві справи немає коду.

#ifdef TONGUE_IN_CHEEK

Perl має таке, gotoщо дозволяє реалізовувати хвостові дзвінки бідолахи. :-P

sub factorial {
    my ($n, $acc) = (@_, 1);
    return $acc if $n < 1;
    @_ = ($n - 1, $acc * $n);
    goto &factorial;
}

#endif

Гаразд, так що це не має нічого спільного з C's goto. Більш серйозно, я погоджуюся з іншими коментарями щодо використання gotoдля очищення чи використання пристрою Даффа тощо. Вся справа в тому, щоб використовувати, не зловживати.

(Цей самий коментар може стосуватися longjmpвинятків call/ccтощо), вони мають законне використання, але їх можна легко зловживати. Наприклад, викидання виключення, щоб уникнути глибоко вкладеної структури управління, за зовсім не виняткових обставин .)

За ці роки я написав більше декількох рядків мови складання. Зрештою, кожна мова високого рівня складається до gotos. Гаразд, назвіть їх "гілками" чи "стрибками" чи ще, але вони - готи. Чи може хто-небудь написати асемблер goto?

Тепер впевнений, що ви можете вказати програмісту Fortran, C або BASIC, що запускати бунт з готосом - це рецепт болонізу для спагетті. Однак відповідь не уникнути їх, а обережно їх використовувати.

Ніж можна використовувати для приготування їжі, звільнення когось або когось убити. Чи обходимося ми без ножів через страх останніх? Аналогічно goto: використовуючи недбало, це перешкоджає, ретельно використовувати це допомагає.

Погляньте, коли використовувати Goto при програмуванні на C :

Хоча використання goto майже завжди є поганою практикою програмування (напевно, ви можете знайти кращий спосіб виконання XYZ), бувають випадки, коли це дійсно не поганий вибір. Деякі можуть навіть стверджувати, що коли це корисно, це найкращий вибір.

Більшість того, що я маю сказати про goto, дійсно стосується лише C. Якщо ви використовуєте C ++, немає надійних причин використовувати goto замість винятків. Однак у C у вас немає механізму обробки винятків, тому якщо ви хочете відокремити обробку помилок від іншої логіки програми, і ви хочете уникнути повторного запису очищення коду кілька разів протягом усього коду, то гото може стати хорошим вибором.

Що я маю на увазі? У вас може бути якийсь код, який виглядає приблизно так:

int big_function()
{
    /* do some work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* do some more work */
    if([error])
    {
        /* clean up*/
        return [error];
    }
    /* clean up*/
    return [success];
}

Це добре, поки ви не зрозумієте, що вам потрібно змінити код очищення. Тоді вам доведеться пройти і внести 4 зміни. Тепер ви можете вирішити, що ви можете просто інкапсулювати всю очистку в одну функцію; це не погана ідея. Але це означає, що вам потрібно бути обережними з покажчиками - якщо ви плануєте звільнити вказівник у вашій функції очищення, немає способу встановити його, щоб потім вказати на NULL, якщо ви не перейдете вказівник на покажчик. У багатьох випадках ви більше не будете використовувати цей покажчик, так що це може не викликати особливих проблем. З іншого боку, якщо ви додасте новий покажчик, ручку файлу чи іншу річ, яка потребує очищення, вам потрібно буде знову змінити функцію очищення; і тоді вам потрібно буде змінити аргументи на цю функцію.

Використовуючи goto, буде

int big_function()
{
    int ret_val = [success];
    /* do some work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
    /* do some more work */
    if([error])
    {
        ret_val = [error];
        goto end;
    }
end:
    /* clean up*/
    return ret_val;
}

Перевага тут полягає в тому, що ваш код після закінчення має доступ до всього, що буде потрібно для очищення, і вам вдалося значно зменшити кількість точок зміни. Ще одна перевага полягає в тому, що ви перейшли від декількох точок виходу для вашої функції до лише однієї; немає шансів, що ви випадково повернетеся з функції без очищення.

Більше того, оскільки goto використовується лише для переходу до однієї точки, це не так, якби ви створюєте масу коду спагетті, стрибаючи туди-сюди, намагаючись імітувати виклики функцій. Швидше, goto насправді допомагає писати більш структурований код.

Одним словом, gotoзавжди слід користуватися економно і в крайньому випадку - але для цього є час і місце. Питання має полягати не в тому, "чи потрібно вам його використовувати", а "чи це найкращий вибір", щоб ним користуватися.

Однією з причин goto є поганий, окрім стилю кодування є те, що ви можете використовувати його для створення перекриваються , але не вкладених циклів:

loop1:
  a
loop2:
  b
  if(cond1) goto loop1
  c
  if(cond2) goto loop2

Це створило б химерну, але можливо юридичну структуру потоку контролю, де можлива послідовність типу (a, b, c, b, a, b, a, b, ...), що робить хакерів компілятора нещасними. Мабуть, існує ряд хитромудрих оптимізаційних хитрощів, які покладаються на те, що цей тип структури не виникає. (Я повинен перевірити свою копію книги дракона ...) Результатом цього може бути (використовуючи деякі компілятори), що інші оптимізації не робляться для коду, що містить gotos.

Це може бути корисно, якщо ви знаєте це просто, "до речі", це переконує компілятора випромінювати швидший код. Особисто я хотів би спробувати пояснити компілятору про те, що ймовірно, а що не до того, як використовувати такий трюк, як goto, але, мабуть, я можу також спробувати gotoперед тим, як зламати асемблер.

Мені здається смішним, що деякі люди підуть так далеко, щоб подати список випадків, коли гото є прийнятним, кажучи, що всі інші види використання неприйнятні. Ви справді думаєте, що знаєте кожен випадок, коли goto - найкращий вибір для вираження алгоритму?

Для ілюстрації я наведу вам приклад, який ще ніхто тут не показав:

Сьогодні я писав код для вставки елемента в хеш-таблицю. Хеш-таблиця - це кеш попередніх обчислень, який можна перезаписати за бажанням (що впливає на продуктивність, але не на правильність).

Кожне відро хеш-таблиці має 4 слоти, і у мене є маса критеріїв, щоб вирішити, який елемент перезаписати, коли відро заповнене. Зараз це означає робити до трьох проходів через відро, як це:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    goto add;

// Otherwise, find first empty element
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
    goto add;

// Additional passes go here...

add:
// element is written to the hash table here

Тепер, якби я не використовував goto, як виглядатиме цей код?

Щось на зразок цього:

// Overwrite an element with same hash key if it exists
for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
  if (slot_p[add_index].hash_key == hash_key)
    break;

if (add_index >= ELEMENTS_PER_BUCKET) {
  // Otherwise, find first empty element
  for (add_index=0; add_index < ELEMENTS_PER_BUCKET; add_index++)
    if ((slot_p[add_index].type == TT_ELEMENT_EMPTY)
      break;
  if (add_index >= ELEMENTS_PER_BUCKET)
   // Additional passes go here (nested further)...
}

// element is written to the hash table here

Це виглядало б гірше і гірше, якщо додано більше пропусків, тоді як версія з goto зберігає той самий рівень відступу в усі часи і уникає використання помилкових, якщо заяви, результат яких мається на увазі під час виконання попереднього циклу.

Отже, є ще один випадок, коли goto робить код більш чистим і простіше писати та розуміти ... Я впевнений, що їх існує ще багато, тому не прикидайтесь, що знаєте всі випадки, коли goto корисно, відмовляючись від будь-яких хороших, які ви не могли не думаю.

Правило з goto, яке ми використовуємо, полягає в тому, що для переходу вперед до однієї точки очищення виходу у функції переходить до goto. У дійсно складних функціях ми розслабляємо це правило, щоб дозволити іншим стрибати вперед. В обох випадках ми уникаємо глибоко вкладених, якщо твердження, які часто трапляються при перевірці коду помилки, що сприяє читанню та збереженню.

Найбільш продумане та ретельне обговорення тверджень goto, їх законного використання та альтернативних конструкцій, які можна використовувати замість "доброчесних заяв goto", але їх можна зловживати так само легко, як goto заяви, - це стаття Дональда Кнута " Структуроване програмування з goto Statements ". , в обчислювальних обстеженнях у грудні 1974 р. (том 6, № 4. С. 261 - 301).

Не дивно, що деякі аспекти цієї 39-річної статті датовані: збільшення наказів на збільшення потужностей обробки робить деякі поліпшення продуктивності Knuth непомітними для проблем середнього розміру, і з цього часу були винайдені нові конструкції на мові програмування. (Наприклад, блоки із спробним уловленням містять конструкцію Зана, хоча вони рідко використовуються таким чином.) Але Кнут охоплює всі сторони аргументу, і його потрібно прочитати, перш ніж хтось ще раз перегляне проблему.

У модулі Perl ви час від часу хочете створювати підпрограми або закриття на льоту. Річ у тім, що як тільки ви створили підпрограму, як до неї дістатися. Ви можете просто зателефонувати, але тоді, якщо підпрограма використовується, caller()вона не буде настільки корисною, як це могло б бути. Саме тут goto &subroutineваріація може бути корисною.

Ось короткий приклад:

sub AUTOLOAD{
  my($self) = @_;
  my $name = $AUTOLOAD;
  $name =~ s/.*:://;

  *{$name} = my($sub) = sub{
    # the body of the closure
  }

  goto $sub;

  # nothing after the goto will ever be executed.
}

Ви також можете використовувати цю форму gotoдля надання рудиментарної форми оптимізації хвостових викликів.

sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;

  $tally *= $n--;
  @_ = ($n,$tally);
  goto &factorial;
}

(У версії 16 Perl 5, яку краще записати як goto __SUB__;)

Є модуль, який імпортує tailмодифікатор, та модуль, який імпортуватиме, recurякщо вам не подобається використовувати цю форму goto.

use Sub::Call::Tail;
sub AUTOLOAD {
  ...
  tail &$sub( @_ );
}

use Sub::Call::Recur;
sub factorial($){
  my($n,$tally) = (@_,1);

  return $tally if $n <= 1;
  recur( $n-1, $tally * $n );
}

Більшість інших причин використання gotoкраще виконувати з іншими ключовими словами.

Як redoі трохи коду:

LABEL: ;
...
goto LABEL if $x;

{
  ...
  redo if $x;
}

Або переходимо до lastкоду з декількох місць:

goto LABEL if $x;
...
goto LABEL if $y;
...
LABEL: ;

{
  last if $x;
  ...
  last if $y
  ...
}

Якщо так, то чому?

C не має багаторівневого / міченого розриву, і не всі контрольні потоки можуть бути легко змодельовані за допомогою ітерації та примитивації рішення C. готи йдуть довгим шляхом до усунення цих вад.

Іноді зрозуміліше використовувати якусь змінну прапора для здійснення свого роду псевдо-багаторівневого розриву, але це не завжди перевершує Goto (принаймні, goto дозволяє легко визначити, куди йде управління, на відміну від змінної прапора ), а іноді ви просто не хочете платити працездатність прапорів / інших викривлень, щоб уникнути переходу.

libavcodec - чутливий до продуктивності фрагмент коду. Пряме вираження контрольного потоку, мабуть, є пріоритетним, оскільки воно, як правило, працює краще.

Так само, як ніхто ніколи не реалізовував заяву "ПРИЙДІТЬ ВІД" ....

Я вважаю, що використання {} в той час, коли (помилкове) використання є абсолютно відштовхуючим. Можливо, це може переконати мене, що це необхідно в якомусь дивному випадку, але ніколи це не чистий розумний код.

Якщо вам потрібно зробити такий цикл, чому б не зробити явну залежність від змінної прапора?

for (stepfailed=0 ; ! stepfailed ; /*empty*/)

1) Найбільш поширене використання goto, про яке я знаю, - це емуляція обробки винятків на мовах, які не пропонують його, а саме в C. (Код, наведений Nuclear вище, саме такий.) Подивіться на вихідний код Linux, і ви ' побачимо використаний таким чином мільйон готів; За даними короткого опитування, проведеного у 2013 році, у коді Linux було близько 100 000 готів: http://blog.regehr.org/archives/894 . Використання Goto навіть згадується в посібнику зі стилю кодування Linux: https://www.kernel.org/doc/Documentation/CodingStyle . Як і об'єктно-орієнтоване програмування емулюється за допомогою структур, заповнених функціональними покажчиками, goto має своє місце в програмуванні на C. Отже, хто правий: Dijkstra чи Linus (і всі кодери ядра Linux)? Це в основному теорія проти практики.

Однак існує звичайна проблема, коли немає підтримки на рівні компілятора та перевірки на загальні конструкції / шаблони: простіше використовувати їх неправильно та вводити помилки без перевірки часу компіляції. Windows і Visual C ++, але в режимі C пропонують обробку винятків через SEH / VEH саме з цієї причини: винятки корисні навіть за межами мов OOP, тобто на процедурній мові. Але компілятор не завжди може зберегти ваш бекон, навіть якщо він пропонує синтаксичну підтримку винятків у мові. Розглянемо як приклад останнього випадку знамениту помилку Apple SSL "goto fail", яка просто копіювала один goto з катастрофічними наслідками ( https://www.imperialviolet.org/2014/02/22/applebug.html ):

if (something())
  goto fail;
  goto fail; // copypasta bug
printf("Never reached\n");
fail:
  // control jumps here

Ви можете мати абсолютно таку ж помилку, використовуючи винятки, підтримувані компілятором, наприклад у C ++:

struct Fail {};

try {
  if (something())
    throw Fail();
    throw Fail(); // copypasta bug
  printf("Never reached\n");
}
catch (Fail&) {
  // control jumps here
}

Але обох варіантів помилки можна уникнути, якщо компілятор аналізує та попереджає про недоступний код. Наприклад, компіляція з Visual C ++ на рівні попередження / W4 знаходить помилку в обох випадках. Наприклад, Java забороняє недоступний код (де його можна знайти!) З досить вагомої причини: це, ймовірно, помилка в середньому коді Джо. Поки конструкція goto не дозволяє цілям, які компілятор не може легко визначити, як-от gotos для обчислених адрес (**), компілятору не важче знайти недоступний код всередині функції з gotos, ніж використовувати Dijkstra -затверджений код.

(**) Зноска: готос до обчислених номерів рядків можливий у деяких версіях Basic, наприклад, GOTO 10 * x, де x - змінна. Досить заплутано, у Fortran "обчислений goto" посилається на конструкцію, еквівалентну оператору перемикання в C. Стандартний C не дозволяє обчислювати готи в мові, а лише gotos статично / синтаксично оголошені мітки. Однак GNU C має розширення, щоб отримати адресу мітки (оператор Unary, префікс &&), а також дозволяє перейти до змінної типу void *. Дивіться https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html для отримання додаткової інформації про цю неясну підтему. Решта цієї публікації не стосується цієї незрозумілої функції GNU C.

Стандартні C (тобто не обчислені) gotos зазвичай не є причиною того, що недоступний код не може бути знайдений під час компіляції. Звичайна причина - логічний код, як показано нижче. Дано

int computation1() {
  return 1;
}

int computation2() {
  return computation1();
}

Компілятору так само важко знайти недосяжний код у будь-якій з наступних 3 конструкцій:

void tough1() {
  if (computation1() != computation2())
    printf("Unreachable\n");
}

void tough2() {
  if (computation1() == computation2())
    goto out;
  printf("Unreachable\n");
out:;
}

struct Out{};

void tough3() {
  try {
    if (computation1() == computation2())
      throw Out();
    printf("Unreachable\n");
  }
  catch (Out&) {
  }
}

(Вибачте мій стиль кодування, пов'язаний з дужками, але я намагався зберегти приклади максимально компактними.)

Visual C ++ / W4 (навіть з / Ox) не вдається знайти недоступний код у будь-якому з них, і, як ви, напевно, знаєте, проблема пошуку недосяжного коду взагалі не може бути вирішена. (Якщо ви мені не вірите в цьому: https://www.cl.cam.ac.uk/teaching/2006/OptComp/slides/lecture02.pdf )

Як пов'язаний з цим проблем, гото C може використовуватися для імітації винятків лише в тілі функції. Стандартна бібліотека C пропонує пару функцій setjmp () та longjmp () для емуляції нелокальних виходів / винятків, але вони мають деякі серйозні недоліки порівняно з іншими мовами. Стаття у Вікіпедії http://en.wikipedia.org/wiki/Setjmp.h досить добре пояснює цю останню проблему. Ця функційна пара також працює в Windows ( http://msdn.microsoft.com/en-us/library/yz2ez4as.aspx ), але навряд чи хтось їх використовує там, оскільки SEH / VEH є вищим. Навіть на Unix, я думаю, що setjmp та longjmp дуже рідко використовуються.

2) Я думаю, що другим найпоширенішим використанням goto в C є реалізація багаторівневої перерви або багаторівневого продовження, що також є досить неперервним випадком використання. Нагадаємо, що Java не дозволяє перейти до мітки goto, але дозволяє перервати мітку або продовжити мітку. За даними http://www.oracle.com/technetwork/java/simple-142616.html , це фактично найпоширеніший випадок використання готів у С (90% вони кажуть), але, на мій суб'єктивний досвід, системний код має тенденцію частіше використовувати gotos для обробки помилок. Можливо, в науковому коді або там, де ОС пропонує обробку виключень (Windows), тоді багаторівневі виходи є домінуючим випадком використання. Вони насправді не дають деталей щодо контексту свого опитування.

Відредаговано, щоб додати: виявляється, ці дві схеми використання знайдені в книзі С Керніган і Річі, приблизно на сторінці 60 (залежно від видання). Ще одне, що слід зазначити, що обидва випадки використання включають лише готи вперед. І виявляється, що MISRA C 2012 видання (на відміну від видання 2004 року) тепер дозволяє готос, якщо вони є лише форвардами.

Деякі кажуть, що немає жодних причин для goto на C ++. Деякі кажуть, що в 99% випадків є кращі альтернативи. Це не міркування, а лише нераціональні враження. Ось вагомий приклад, коли goto призводить до хорошого коду, щось на кшталт розширеного циклу "час роботи":

int i;

PROMPT_INSERT_NUMBER:
  std::cout << "insert number: ";
  std::cin >> i;
  if(std::cin.fail()) {
    std::cin.clear();
    std::cin.ignore(1000,'\n');
    goto PROMPT_INSERT_NUMBER;          
  }

std::cout << "your number is " << i;

Порівняйте його з безкоштовним кодом:

int i;

bool loop;
do {
  loop = false;
  std::cout << "insert number: ";
  std::cin >> i;
  if(std::cin.fail()) {
    std::cin.clear();
    std::cin.ignore(1000,'\n');
    loop = true;          
  }
} while(loop);

std::cout << "your number is " << i;

Я бачу ці відмінності:

• вкладений {}блок потрібен (хоч і do {...} whileвиглядає більш звично)
• loopпотрібна додаткова змінна, яка використовується в чотирьох місцях
• потрібно більше часу, щоб прочитати та зрозуміти роботу з loop
• loopне має яких - небудь даних, він просто контролює потік виконання, який є менш зрозумілим , ніж просто етикетки

Є ще один приклад

void sort(int* array, int length) {
SORT:
  for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
    swap(data[i], data[i+1]);
    goto SORT; // it is very easy to understand this code, right?
  }
}

Тепер давайте позбудемося "зла" гото:

void sort(int* array, int length) {
  bool seemslegit;
  do {
    seemslegit = true;
    for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
      swap(data[i], data[i+1]);
      seemslegit = false;
    }
  } while(!seemslegit);
}

Ви бачите, що це один і той же тип використання goto, це добре структурована структура, і це не передання goto стільки реклами, як єдиний рекомендований спосіб. Напевно ви хочете уникнути "розумного" коду, як це:

void sort(int* array, int length) {
  for(int i=0; i<length-1; ++i) if(array[i]>array[i+1]) {
    swap(data[i], data[i+1]);
    i = -1; // it works, but WTF on the first glance
  }
}

Справа в тому, що Goto можна легко використати, але сам goto не винен. Зауважте, що мітка має функціональну область в C ++, тому вона не забруднює глобальну область застосування, як у чистому складі, в якій петлі , що перекриваються, мають своє місце і дуже поширені - як у наступному коді для 8051, де 7-сегментний дисплей підключений до P1. Програма замикає сегмент блискавки навколо:

; P1 states loops
; 11111110 <-
; 11111101  |
; 11111011  |
; 11110111  |
; 11101111  |
; 11011111  |
; |_________|

init_roll_state:
    MOV P1,#11111110b
    ACALL delay
next_roll_state:
    MOV A,P1
    RL A
    MOV P1,A
    ACALL delay
    JNB P1.5, init_roll_state
    SJMP next_roll_state

Є ще одна перевага: goto може служити названими петлями, умовами та іншими потоками:

if(valid) {
  do { // while(loop)

// more than one page of code here
// so it is better to comment the meaning
// of the corresponding curly bracket

  } while(loop);
} // if(valid)

Або ви можете використовувати еквівалентний goto з відступом, тому вам не потрібен коментар, якщо ви вибираєте ім'я мітки:

if(!valid) goto NOTVALID;
  LOOPBACK:

// more than one page of code here

  if(loop) goto LOOPBACK;
NOTVALID:;

У Perl використовуйте мітку для "goto" з циклу - використовуючи операцію "last", яке схоже на розрив.

Це дозволяє краще контролювати вкладені петлі.

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

Проблема з "goto" та найважливішим аргументом руху "goto-programming '" полягає в тому, що якщо ви використовуєте його занадто часто, ваш код, хоча він може вести себе правильно, стає нечитабельним, незбагненним, не переглядається тощо. У 99,99% випадки 'goto' призводять до коду спагетті. Особисто я не можу придумати жодної вагомої причини щодо того, чому б я використовував "goto".

Звичайно, GOTO можна використовувати, але є ще одна важлива річ, ніж стиль коду, або якщо код є читливим чи не читабельним, що ви повинні мати на увазі, коли ви його використовуєте: код всередині може бути не таким надійним, як ви думати .

Наприклад, подивіться на наступні два фрагменти коду:

If A <> 0 Then A = 0 EndIf
Write("Value of A:" + A)

Еквівалентний код з GOTO

If A == 0 Then GOTO FINAL EndIf
   A = 0
FINAL:
Write("Value of A:" + A)

Перше, що ми думаємо, це те, що результатом обох бітів коду буде те, що "Значення A: 0" (звичайно, ми припускаємо виконання без паралелізму)

Це не правильно: у першому зразку A завжди буде 0, але у другому зразку (із заявою GOTO) A може бути не 0. Чому?

Причина полягає в тому, що з іншого пункту програми я можу вставити а, GOTO FINALне контролюючи значення A.

Цей приклад є дуже очевидним, але оскільки програми ускладнюються, складність бачити такі речі збільшується.

Матеріали, пов'язані з цим матеріалом, можна знайти у відомій статті пана Дійкстри "Справа проти заяви GO TO"

Я використовую goto в наступному випадку: коли потрібно повернутися з функцій в різних місцях, і перед поверненням потрібно зробити деякі неініціалізації:

не-goto версія:

int doSomething (struct my_complicated_stuff *ctx)    
{
    db_conn *conn;
    RSA *key;
    char *temp_data;
    conn = db_connect();  


    if (ctx->smth->needs_alloc) {
      temp_data=malloc(ctx->some_size);
      if (!temp_data) {
        db_disconnect(conn);
        return -1;      
        }
    }

    ...

    if (!ctx->smth->needs_to_be_processed) {
        free(temp_data);    
        db_disconnect(conn);    
        return -2;
    }

    pthread_mutex_lock(ctx->mutex);

    if (ctx->some_other_thing->error) {
        pthread_mutex_unlock(ctx->mutex);
        free(temp_data);
        db_disconnect(conn);        
        return -3;  
    }

    ...

    key=rsa_load_key(....);

    ...

    if (ctx->something_else->error) {
         rsa_free(key); 
         pthread_mutex_unlock(ctx->mutex);
         free(temp_data);
         db_disconnect(conn);       
         return -4;  
    }

    if (ctx->something_else->additional_check) {
         rsa_free(key); 
         pthread_mutex_unlock(ctx->mutex);
         free(temp_data);
         db_disconnect(conn);       
         return -5;  
    }


    pthread_mutex_unlock(ctx->mutex);
    free(temp_data);    
    db_disconnect(conn);    
    return 0;     
}

goto версія:

int doSomething_goto (struct my_complicated_stuff *ctx)
{
    int ret=0;
    db_conn *conn;
    RSA *key;
    char *temp_data;
    conn = db_connect();  


    if (ctx->smth->needs_alloc) {
      temp_data=malloc(ctx->some_size);
      if (!temp_data) {
            ret=-1;
           goto exit_db;   
          }
    }

    ...

    if (!ctx->smth->needs_to_be_processed) {
        ret=-2;
        goto exit_freetmp;      
    }

    pthread_mutex_lock(ctx->mutex);

    if (ctx->some_other_thing->error) {
        ret=-3;
        goto exit;  
    }

    ...

    key=rsa_load_key(....);

    ...

    if (ctx->something_else->error) {
        ret=-4;
        goto exit_freekey; 
    }

    if (ctx->something_else->additional_check) {
        ret=-5;
        goto exit_freekey;  
    }

exit_freekey:
    rsa_free(key);
exit:    
    pthread_mutex_unlock(ctx->mutex);
exit_freetmp:
    free(temp_data);        
exit_db:
    db_disconnect(conn);    
    return ret;     
}

Друга версія полегшує роботу, коли вам потрібно щось змінити в операторах делокації (кожен використовується один раз у коді), і зменшує шанс пропустити будь-яку з них, додаючи нову гілку. Переміщення їх у функції тут не допоможе, оскільки угода може бути здійснена на різних "рівнях".

Едсгер Дайкстра, комп'ютерний вчений, який мав великий внесок у цю сферу, також був відомий тим, що критикував використання GoTo. У Вікіпедії є коротка стаття про його аргумент .

Це зручно час від часу обробляти рядки символами.

Уявіть щось на зразок цього printf-esque прикладу:

for cur_char, next_char in sliding_window(input_string) {
    if cur_char == '%' {
        if next_char == '%' {
            cur_char_index += 1
            goto handle_literal
        }
        # Some additional logic
        if chars_should_be_handled_literally() {
            goto handle_literal
        }
        # Handle the format
    }
    # some other control characters
    else {
      handle_literal:
        # Complicated logic here
        # Maybe it's writing to an array for some OpenGL calls later or something,
        # all while modifying a bunch of local variables declared outside the loop
    }
}

Ви можете відновити це goto handle_literalдо виклику функції, але якщо він модифікує кілька різних локальних змінних, вам доведеться передати посилання на кожну, якщо ваша мова не підтримує змінні закриття. continueПісля виклику вам все одно доведеться використовувати оператор (який, можливо, є формою goto), щоб отримати ту саму семантику, якщо ваша логіка робить інакший випадок недійсним.

Я також використовував готос розумно в лексемах, як правило, для подібних випадків. Вони вам не потрібні більшість часу, але їх приємно мати для тих дивних випадків.