GOTO, который все еще рассматривают вредным? [закрытый]

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

Я на самом деле нашел меня вынужденным использовать goto, потому что я буквально не мог думать о лучшем (более быстром) способе записать этот код:

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

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

Это было в скорости критическая часть кода UI в реальном времени, таким образом, я честно думаю, что GOTO был выровнен по ширине здесь.

Hugo

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

It’s, не стоящий того.

Я могу только вспомнить использование goto однажды. У меня была серия пяти вложенных считаемых циклов, и я должен был быть в состоянии убежать из всей структуры с внутренней части рано на основе определенных условий:

for{
  for{
    for{
      for{
        for{
          if(stuff){
            GOTO ENDOFLOOPS;
          }
        }
      }
    }
  }
}

ENDOFLOOPS:

я, возможно, просто легко объявил булеву переменную повреждения и использовал ее в качестве части условного выражения для каждого цикла, но в этом экземпляре я решил, что GOTO был так же практичен и так же читаем.

Никакой velociraptors не напал на меня.

У нас уже был этот обсуждение , и я стою в стороне моя точка .

, Кроме того, я сыт по горло людьми, описывающими высокоуровневые структуры языка как “ goto в disguise”, потому что у них ясно нет точки во всем . Например:

Даже усовершенствованная управляющая структура продолжения в Схеме может быть описана как сложный goto.

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

Точно так же высказывание “GOTO является инструментом, и как всеми инструментами, это может использоваться, и abused” полностью от метки. Никакой современный рабочий-строитель не использовал бы скалу и требовал бы его “is инструмент. Скалы ” были заменены молотками. goto был заменен управляющими структурами. Если бы рабочий-строитель был скручен в дикой природе без молотка, конечно, он использовал бы скалу вместо этого. Если программист должен использовать нижний язык программирования, который не имеет функции X, ну, в общем, конечно, ей, вероятно, придется использовать goto вместо этого. Но если она использует его где-нибудь еще вместо соответствующей функции языка, она ясно не поняла язык правильно и использует его неправильно. Это действительно настолько просто.

Goto является чрезвычайно низким в моем списке вещей включать в программу только ради него. Это не означает, что это недопустимо.

Goto может быть хорошим для конечных автоматов. Оператор переключения в цикле (в порядке типичной важности): (a) не на самом деле представительный для потока управления, (b) ужасный, (c) потенциально неэффективный в зависимости от языка и компилятора. Таким образом, Вы заканчиваете тем, что писали одну функцию на состояние и сделали вещи как "возврат NEXT_STATE"; которые даже похожи на goto.

Предоставленный, трудно кодировать конечные автоматы способом, которые делают их легкими понять. Однако ничего подобного, трудность относится к использованию goto и ни одному из него, не может быть уменьшен при помощи альтернативных управляющих структур. Если Ваш язык не имеет конструкцию 'конечного автомата'. Мой не делает.

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

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

setjmp/longjmp 'более опасны', чем goto в том смысле, что их более трудно использовать правильно, не берите в голову понятно.

никогда не было, и при этом никогда не будет, никакой язык, на котором это - наименее разрядное трудное для записи плохого кода. - Donald Knuth.

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

Следующий это будут "указатели, которые рассматривают вредными", тогда "утиный ввод, который рассматривают вредным". Тогда, кого оставят защитить Вас, когда они прибудут для убирания небезопасной конструкции программирования? А?

В Linux: Используя goto В Коде Ядра на Прерывании Ядра, существует обсуждение с Linus Torvalds и "новым парнем" об использовании GOTOs в коде Linux. Существуют некоторые очень положительные стороны там и Linus, одетый в то обычное высокомерие:)

Некоторые проходы:

Linus: "нет, Вам промыли мозги люди CS, которые думали, что Niklaus Wirth на самом деле знал то, о чем он говорил. Он не сделал. У него нет трахающей подсказки".

-

Linus: "Я думаю, что goto's прекрасен, и они часто более читаемы, чем большие объемы добавления отступа".

-

Linus: "Конечно, на глупых языках как Паскаль, где маркировки не могут быть описательными, goto's может быть плохим".

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

я полагаю, что опасность goto в C значительно преувеличена. Помните, что исходные goto аргументы произошли назад в эпоху языков как ОСНОВНОЙ старомодный, где новички запишут запутанный код как это:

3420 IF A > 2 THEN GOTO 1430

Здесь Linus описывает соответствующее использование goto: http://www.kernel.org/doc/Documentation/CodingStyle (глава 7).

Donald E. Knuth ответил на этот вопрос в книге "Грамотное программирование", 1992 CSLI. На p. 17 существует эссе" Структурное программирование с операторами перехода " (PDF). Я думаю, что статья, возможно, была опубликована в других книгах также.

статья описывает предложение Dijkstra и описывает обстоятельства, где это допустимо. Но он также дает много встречных примеров (проблемы и алгоритмы), который не может быть легко воспроизведен с помощью структурированных циклов только.

статья содержит полное описание проблемы, историю, примеры и встречные примеры.

Притянутый Jay Ballou, добавляющим ответ, добавлю я свой ВЈ0.02. Если бы Bruno Ranschaert уже не сделал так, то я упомянул бы статью "Structured Programming with GOTO Statements" Knuth.

Одной вещью, которую я не видел обсужденный, является вид кода, который, в то время как не точно распространенный, преподавался в учебниках Фортрана. Вещи как расширенный диапазон цикла типа DO и открыто кодированных подпрограмм (помнят, это был бы Фортран II или Фортран IV или Фортран 66 - не Фортран 77 или 90). Существует, по крайней мере, шанс, что синтаксические детали неточны, но понятия должны быть достаточно точными. Отрывки в каждом случае в единственной функции.

Примечание, которое превосходные, но датированное (и распроданный) заказывают' Элементы Стиля программирования, 2-й Edn' Kernighan & Plauger включает некоторые реальные примеры злоупотребления GOTO от программирования учебников его эры (последние 70-е). Материал ниже не из той книги, как бы то ни было.

Расширенный диапазон для цикла типа DO

       do 10 i = 1,30
           ...blah...
           ...blah...
           if (k.gt.4) goto 37
91         ...blah...
           ...blah...
10     continue
       ...blah...
       return
37     ...some computation...
       goto 91

Одной причиной такой ерунды была хорошая старомодная перфокарта. Вы могли бы заметить, что маркировки (приятно из последовательности, потому что это было каноническим стилем!) находятся в столбце 1 (на самом деле, они должны были быть в столбцах 1-5), и код находится в столбцах 7-72 (столбец 6 был столбцом маркера продолжения). Столбцам 73-80 дали бы порядковый номер, и были машины, которые отсортируют деки перфокарты в порядок порядкового номера. Если бы Вы имели свою программу на упорядоченных картах и должны были добавить несколько карт (строки) в середину цикла, то необходимо будет повторно перфорировать все после тех дополнительных строк. Однако при замене одной карты материалом GOTO Вы могли бы постараться не повторно упорядочивать все карты - Вы просто подвернули новые карты в конце стандартной программы с новыми порядковыми номерами. Полагайте, что это первая попытка '"зеленых" вычислений' - сохранения перфокарт (или, более конкретно, сохранения перепечатывания труда - и сохранения последовательных ошибок повторного ввода).

, О, Вы могли бы также отметить, что я обманываю и не кричу - Фортран, который IV обычно писался во всем верхнем регистре.

Открыто кодированная подпрограмма

       ...blah...
       i = 1
       goto 76
123    ...blah...
       ...blah...
       i = 2
       goto 76
79     ...blah...
       ...blah...
       goto 54
       ...blah...
12     continue
       return
76     ...calculate something...
       ...blah...
       goto (123, 79) i
54     ...more calculation...
       goto 12

GOTO между маркирует 76, и 54 версия вычисленного goto. Если переменная у меня есть значение 1, goto первая маркировка в списке (123); если это имеет значение 2, goto второе, и так далее. Фрагмент от 76 до вычисленного goto является открыто кодированной подпрограммой. Это была часть кода, выполненного скорее как подпрограмма, но выписанного в теле функции. (Фортран также имел функции оператора - которые были встроены функции, которые соответствовали на одной строке.)

были худшие конструкции, чем вычисленный goto - Вы могли присвоить маркировки переменным и затем использовать присвоенный goto. При поиске с помощью Google присвоенный goto говорит мне, что был удален из Фортрана 95. Запишите на свой счет один для оборота структурного программирования, который, как могли справедливо говорить, запустил на публике с "GOTO Dijkstra Продуманную Вредную" букву или статью.

Без некоторого ведома видов вещей, которые были сделаны в Фортране (и на других языках, большинство которых справедливо оказалось нереально), нам вновь прибывшие трудно понять объем проблемы, с которой имел дело Dijkstra. Heck, я не начинал программировать до десяти лет после того, как та буква была опубликована (но у меня действительно была неудача к программе в Фортране IV некоторое время).

Если бы сами GOTO были злыми, компиляторы были бы злыми, потому что они генерируют JMPs. Если вскакивание в блок кода, особенно после указателя, было по сути злым, инструкция по Возврату будет злой. Скорее зло находится в потенциале для злоупотребления.

Время от времени я должен был записать приложения, которые должны были отслеживать много объектов, где каждый объект должен был следовать за сложной последовательностью состояний в ответ на события, но все это было определенно единственным потоком. Типичная последовательность состояний, если представлено в псевдокоде была бы:

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

я уверен, что это не является новым, но способ, которым я обработал его в C (++), состоял в том, чтобы определить некоторые макросы:

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

Тогда (принимающий состояние первоначально 0) структурированный конечный автомат выше превращается в структурированный код:

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

С изменением на этом, может быть ВЫЗОВ и ВОЗВРАТ, таким образом, некоторые конечные автоматы могут действовать как подпрограммы других конечных автоматов.

действительно ли это необычно? Да. Требуется некоторое изучение со стороны специалиста по обслуживанию? Да. Это учение наизусть платит? Я думаю так. Это могло обойтись без GOTOs, которые вскакивают в блоки? Нет.

Нет таких вещей как GOTO, которую рассматривают вредной .

GOTO является инструментом, и как всеми инструментами, он может использоваться, и злоупотребил .

существуют, однако, много инструментов в мире программирования, которые имеют тенденцию быть , злоупотребили [еще 112], чем быть использовало , и GOTO является одним из них. оператор WITH Дельфи - другой.