ПЕРЕЙТИ или НЕ ПЕРЕЙТИ?

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

Я не уверен, что вы имеете в виду под чистым кодом, но в C++ есть концепция под названием «получение ресурсов - это инициализация», и ваши деструкторы должны нести ответственность за очистку материала.

(Обратите внимание, что в C# и Java это обычно решается с помощью try / finally)

Для получения дополнительной информации посетите эту страницу: http://www.research.att.com/~bs/bs_faq2.html#finally

РЕДАКТИРОВАТЬ: Позвольте мне немного прояснить это.

Рассмотрим следующий код:

void MyMethod()
{
    MyClass *myInstance = new MyClass("myParameter");
    /* Your code here */
    delete myInstance;
}

Проблема: Что произойдет, если у вас есть несколько выходов из функции? Вы должны следить за каждым выходом и удалять свои объекты при всех возможных выходах! В противном случае у вас будут утечки памяти и зомби-ресурсы, верно?

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

void MyMethod()
{
    MyClass myInstance("myParameter");
    /* Your code here */
    /* You don't need delete - myInstance will be destructed and deleted
     * automatically on function exit */
}

О да, и используйте std::unique_ptr или что-то подобное, потому что приведенный выше пример явно несовершенный.

Использование goto для перехода в раздел очистки вызовет множество проблем.

Во-первых, разделы очистки подвержены проблемам. Они обладают низкой связностью (нет реальной роли, которую можно описать в терминах того, что программа пытается делать), высокой связностью (правильность очень сильно зависит от других разделов кода) и вовсе небезопасны в отношении исключений. Посмотрим, можно ли использовать деструкторы для очистки. Например, если int *p заменен на auto_ptr<int> p, то то, на что указывает p, будет автоматически освобождено.

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

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

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

Наверное, не хорошая идея.

Все вышеперечисленное верно, вы также можете захотеть посмотреть, сможете ли вы уменьшить сложность своего кода и уменьшить потребность в goto, уменьшив количество кода, которое находится в разделе, помеченном как «много кода». в вашем примере. Дополнительно delete 0 является допустимым оператором C++

Ваш код крайне неидиоматичен, и вы никогда не должны его писать. Вы в основном эмулируете C в C++. Но другие отметили это и указали на RAII в качестве альтернативы.

Однако ваш код не будет работать, как вы ожидаете, потому что это:

p = new int;
if (p==NULL) { … }

не Когда-либо оценивает true (кроме случаев, когда вы перегрузили operator new странным образом). Если operator new не может выделить достаточно памяти, он выдает исключение, никогда, Когда-либо возвращает 0, по крайней мере, не с этим набором параметров; существует специальная перегрузка с новым размещением, которая принимает экземпляр типа std::nothrow и действительно возвращает 0 вместо того, чтобы генерировать исключение. Но эта версия редко используется в обычном коде. Некоторые низкоуровневые коды или приложения для встраиваемых устройств могут извлечь выгоду из этого в контекстах, где обработка исключений обходится слишком дорого.

Нечто подобное верно и для вашего блока delete, как сказал Харальд: if (p) не нужен перед delete p.

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

bool foo() // prefer native types to BOOL, if possible
{
    bool ret = false;
    int i;
    // Lots of code.
    return ret;
}

Попробуйте так:

BOOL foo()
{
   BOOL bRetVal = FALSE;
   int *p = NULL;

   p = new int;
   if (p == NULL)
   {
     cout<<" OOM \n";
   }
   else
   {
       // Lot of code...
   }

   if (p)
   {
     delete p;
     p = NULL;
   }
   return bRetVal;
}

В разделе «Много кода» «Много кода» является хорошим показателем того, что вам, вероятно, следует преобразовать этот раздел в один или несколько методов или функций.

Вся цель идиомы «каждая функция имеет единственную точку выхода» в C заключалась в том, чтобы собрать весь материал для очистки в одном месте. Если вы используете деструкторы C++ для обработки очистки, в этом больше нет необходимости - очистка будет выполняться независимо от того, сколько точек выхода имеет функция. Так что в правильно спроектированном коде C++ в подобных вещах больше нет необходимости.

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

Мне всегда удавалось избегать GOTO-команд, поэтому угадайте, когда вы думаете, что они могут вам понадобиться, все, что вам может понадобиться, - это переработать дизайн.

Однако, если мы посмотрим на это на уровне Assmebly, использование «прыжка» похоже на использование GOTO, которое используется все время, НО в Assembly вы можете очистить, что, как вы знаете, у вас есть в стеке, и другие регистры перед вами передай.

Итак, при использовании GOTO, я бы удостоверился, что программное обеспечение будет «появляться», как предполагают со-кодировщики, GOTO окажет «плохое» влияние на ваше программное обеспечение imho.

Так что это скорее объяснение того, почему не использовать GOTO, а не решение для замены, потому что это ОЧЕНЬ зависит от того, как все остальное построено.

Мне никогда не приходилось использовать goto в C++. Всегда. КОГДА-ЛИБО. Если есть ситуация, ее следует использовать, это невероятно редко. Если вы действительно думаете о том, чтобы сделать goto стандартной частью своей логики, что-то пошло не так.

Использование меток GOTO в C++ - плохой способ программирования, вы можете уменьшить потребность, выполнив ОО программирование (деконструкторы!) И попытавшись держать процедуры как можно меньше, насколько это возможно.

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

Вашу процедуру можно было бы просто написать так:

bool foo()
{
    bool bRetVal = false;
    int p = 0;

    // Calls to various methods that do algorithms on the p integer
    // and give a return value back to this procedure.

    return bRetVal;
}

Вы должны поместить блок try catch в основную программу, обрабатывающую проблемы с нехваткой памяти, который информирует пользователя о нехватка памяти, что бывает очень редко ... (разве сама ОС не сообщает об этом?)

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

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

int foo()
{
    int *pWhatEver = ...;
    if (something(pWhatEver))
    { 
        delete pWhatEver;
        return 1;
    }
    else
    {
        delete pWhatEver;
        return 5;
    }
}

И этот код:

int foo()
{
    int ret;
    int *pWhatEver = ...;
    if (something(pWhatEver))
    { 
        ret = 1;
        goto exit;
    }
    else
    {
        ret = 1;
        goto exit;
    }
exit:
    delete pWhatEver;
    return ret;
}

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

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

int foo()
{
    Auto<int> pWhatEver = ...;

    if (something(pWhatEver))
    {
        return 1;
    }
    else
    {
        return 5;
    }
}

короче, легче читается и проще в обслуживании, чем оба предыдущих примера.

Итак, я бы порекомендовал использовать подход RAII, если вы можете.

Поскольку это классическая тема, я отвечу Заявление о переходе считается вредным Дейкстры (изначально опубликовано в ACM).

Все предыдущие комментарии - веские причины не использовать goto.

По своему опыту могу сказать, что другим программистам, которым может понадобиться поддерживать ваш код, очень сложно следовать логике goto. Я попал в ситуацию с тяжелым спагетти-кодом goto, и с моим опытом работы с объектно-ориентированной архитектурой было кошмаром отлаживать и вносить изменения. Да, этот код также использовал goto для функций очистки. Очень неприятно, когда он не нужен. Не используйте goto без крайней необходимости.

Из всех предыдущих комментариев:

1. goto очень-очень плохо
2. Это затрудняет чтение и понимание кода.
3. Это может вызвать известную проблему «спагетти-код».
4. Все согласны с тем, что этого нельзя делать.

Но я использую в следующем сценарии

1. Используется для перехода вперед и только к одному лейблу.
2. Раздел goto используется для очистки кода и установки возвращаемого значения. Если я не использую goto, мне нужно создать класс для каждого типа данных. Как будто мне нужно обернуть int * в класс.
3. Это соблюдается во всем проекте.

Я согласен с тем, что это плохо, но все же при правильном соблюдении это значительно упрощает жизнь.

Я не собираюсь говорить, что goto всегда плох, но вы наверняка его используете. Подобные «разделы очистки» были довольно распространены в начале 1990-х годов, но использовать их для нового кода - чистое зло.

По сути, есть два момента, которые люди делают в отношении gotos и вашего кода:

1. Гото плохой. Очень редко можно встретить место, где вам нужны gotos, но я бы не советовал удалять его полностью. Хотя C++ имеет достаточно умный поток управления, чтобы сделать goto редко подходящим.

2. Ваш механизм очистки неправильный: Этот момент гораздо важнее. В языке C использование управления памятью по своему усмотрению не только нормально, но и зачастую является лучшим способом решения задач. В C++ ваша цель должна состоять в том, чтобы как можно больше избегать управления памятью. Вам следует по возможности избегать управления памятью. Пусть компилятор сделает это за вас. Вместо использования new просто объявите переменные. Единственный случай, когда вам действительно понадобится управление памятью, - это когда вы заранее не знаете размер ваших данных. Даже в этом случае вам следует попытаться использовать вместо этого просто некоторые из коллекций STL.

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

Ваш ответ о том, что ваш способ ведения дел намного проще, в конечном итоге неверен. Во-первых, как только вы прочувствуете C++, создание таких конструкторов станет второстепенным. Лично я считаю, что использовать конструкторы проще, чем использовать код очистки, поскольку мне не нужно уделять особое внимание, чтобы убедиться, что я освобождаю память правильно. Вместо этого я могу просто позволить объекту покинуть область видимости, и язык сделает это за меня. Кроме того, поддерживать их НАМНОГО проще, чем поддерживать раздел очистки, и они гораздо менее подвержены проблемам.

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

Самый простой способ избежать того, что вы здесь делаете, - поместить всю эту очистку в какую-то простую структуру и создать ее экземпляр. Например вместо:

void MyClass::myFunction()
{
   A* a = new A;
   B* b = new B;
   C* c = new C;
   StartSomeBackgroundTask();
   MaybeBeginAnUndoBlockToo();

   if ( ... )
   {
     goto Exit;
   }

   if ( ... ) { .. }
   else
   {
      ... // what happens if this throws an exception??? too bad...
      goto Exit;
   }

Exit:
  delete a;
  delete b;
  delete c;
  StopMyBackgroundTask();
  EndMyUndoBlock();
}

вам лучше выполнить эту очистку следующим образом:

struct MyFunctionResourceGuard
{
  MyFunctionResourceGuard( MyClass& owner ) 
  : m_owner( owner )
  , _a( new A )
  , _b( new B )
  , _c( new C )
  {
      m_owner.StartSomeBackgroundTask();
      m_owner.MaybeBeginAnUndoBlockToo();
  }

  ~MyFunctionResourceGuard()
  {
     m_owner.StopMyBackgroundTask();
     m_owner.EndMyUndoBlock();
  }

  std::auto_ptr<A> _a;
  std::auto_ptr<B> _b;
  std::auto_ptr<C> _c;

};

void MyClass::myFunction()
{
   MyFunctionResourceGuard guard( *this );

   if ( ... )
   {
     return;
   }

   if ( ... ) { .. }
   else
   {
      ...
   }
}

Я думаю, что другие ответы (и их комментарии) охватили все важные моменты, но вот одна вещь, которая еще не была сделана должным образом:

Вместо этого, как должен выглядеть ваш код:

bool foo() //lowercase bool is a built-in C++ type. Use it if you're writing C++.
{
  try {
    std::unique_ptr<int> p(new int);
    // lots of code, and just return true or false directly when you're done
  }
  catch (std::bad_alloc){ // new throws an exception on OOM, it doesn't return NULL
    cout<<" OOM \n";
    return false;
  }
}

Ну, он короче и, насколько я понимаю, более правильный (правильно обрабатывает случай OOM), и, что наиболее важно, мне не нужно было писать какой-либо код очистки или делать что-то особенное, чтобы «убедиться, что мое возвращаемое значение инициализировано ".

Одна проблема с вашим кодом, которую я действительно заметил, когда писал это, - это «какое, черт возьми, значение bRetVal на данный момент?». Я не знаю, потому что выше он был объявлен waaaaay, и когда последний раз он был назначен? В какой-то момент выше этого. Мне нужно прочитать всю функцию, чтобы убедиться, что я понимаю, что будет возвращено.

И как мне убедить себя, что память освобождается?

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

Очень хрупкий код, потому что каждый, когда ресурс должен быть очищен, вам нужно помнить, чтобы дублировать ваш код очистки. Почему бы не написать его один раз в том виде, который нужно очистить? А затем полагаться на его автоматическое выполнение каждый раз, когда нам это нужно?

Ваш пример не безопасен.

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

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

Вам нужно изучить интеллектуальные указатели. В приведенной выше ситуации вы можете просто использовать std::auto_ptr<>.

Также обратите внимание, что в коде C++ нет необходимости проверять, является ли указатель NULL (обычно потому, что у вас никогда нет указателей RAW), но потому что new не вернет NULL (он выдает).

Также в C++, в отличие от (C), часто можно увидеть ранние возвраты в коде. Это связано с тем, что RAII выполнит очистку автоматически, в то время как в коде C вам нужно убедиться, что вы добавили специальный код очистки в конце функции (немного похожий на ваш код).

Возможно, я что-то пропустил: вы переходите к метке Exit, если P имеет значение NULL, затем проверяете, не является ли он нулевым (а это не так), чтобы узнать, нужно ли вам его удалить (что не обязательно, потому что он никогда не был выделен в первое место).

If / goto не будет, и ему не нужно удалять p. Замена goto на return false будет иметь тот же эффект (и тогда вы можете удалить метку Exit).

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

Функции (A вызывает A '), Try / Catches и setjmp / longjmps - все это более хорошие способы избежать сложной синтаксической проблемы.

Павел.

Игнорируя тот факт, что new никогда не вернет NULL, возьмите свой код:

  BOOL foo()
  {
     BOOL bRetVal = FALSE;

     int *p=NULL;

     p = new int;

     if (p==NULL)
     {
        cout<<" OOM \n";
        goto Exit;
     }

     // Lot of code...

  Exit:
     if (p)
     {
        delete p;
        p= NULL;
     }

     return bRetVal;
  }

и напишите это так:

  BOOL foo()
  {
     BOOL bRetVal = FALSE;

     int *p = new int;

     if (p!=NULL)
     {
        // Lot of code...

        delete p;
     }
     else
     {
        cout<<" OOM \n";
     }

     return bRetVal;
  }

Многие люди сходят с ума от gotos - это зло; они не. Тем не менее, он вам никогда не понадобится; почти всегда есть лучший способ.

Когда я обнаруживаю, что мне «нужен» goto для выполнения такого рода действий, я почти всегда обнаруживаю, что мой код слишком сложен и может быть легко разбит на несколько вызовов методов, которые легче читать и с которыми легче работать. Ваш код вызова может делать что-то вроде:

// Setup
if (
     methodA() &&
     methodB() &&
     methodC()
 )
 // Cleanup

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

Однако чтение комментариев должно указать на то, что у вашей команды есть более насущные проблемы, чем решение goto.

В этом коде есть множество проблем, на большинство из которых уже указывалось, например:

• Функция слишком длинная; может помочь рефакторинг некоторого кода в отдельные функции.

• Использование указателей, когда обычные экземпляры, вероятно, будут работать нормально.

• Не использовать преимущества типов STL, таких как auto_ptr

• Неправильная проверка на ошибки, а не отлов исключений. (Я бы сказал, что проверка OOM бессмысленна на подавляющем большинстве платформ, поскольку, если у вас заканчивается память, у вас возникают большие проблемы, чем может исправить ваше программное обеспечение, если только вы не пишете саму ОС)

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

Вы должны прочитать это резюме из списков рассылки ядра Linux (обращая особое внимание на ответы Линуса Торвальдса), прежде чем формировать политику для goto:

http://kerneltrap.org/node/553/2131

Goto обеспечивает лучший не повторяйся (DRY), когда "конечная логика" является общей для некоторых, но не для всех случаев. Особенно в операторе switch я часто использую goto, когда некоторые из ветвей switch имеют конечную общность.

switch(){
   case a:  ... goto L_abTail;
   case b: ... goto L_abTail;
L_abTail: <commmon stuff>
    break://end of case b
case c:
.....
}//switch

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

...
   goto L_skipMiddle;
{
    int declInMiddleVar = 0;
    ....
}
L_skipMiddle: ;

В более поздних версиях Visual Studio, обнаруживающих использование неинициализированных переменных, я обнаружил, что всегда инициализирую большинство переменных, хотя я думаю, что они могут быть назначены во всех ветвях - легко закодировать оператор «трассировки», который ссылается на переменную, которая никогда не была назначена, потому что ваш разум не воспринимает оператор трассировки как «настоящий код», но, конечно, Visual Studio все равно обнаружит ошибку.

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

Конечно, если вы на самом деле выделяете ресурсы, тогда, если auto-ptr не подходит, вам действительно нужно использовать try-catch, но хвостовое слияние-не-повторять-себя происходит довольно часто, когда безопасность исключений Не ошибка.

Таким образом, хотя goto можно использовать для кодирования структур, похожих на спагетти, в случае хвостовой последовательности, которая является общей для некоторых, но не для всех случаев, goto УЛУЧШАЕТ читаемость кода и даже ремонтопригодность. если в противном случае вы будете копировать / вставлять что-то, чтобы намного позже кто-то мог обновить одно, а не другое. Так что это еще один случай, когда фанатичное отношение к какой-либо догме может быть контрпродуктивным.

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

BOOL foo()
{
   BOOL bRetVal = FALSE;
   int *p=NULL;

   do
   {
       p = new int;
       if (p==NULL)
       {
          cout<<" OOM \n";
          break;
       }

       // Lot of code...

       bRetVal = TRUE;

    } while (false);

   if (p)
   {
     delete p;
     p= NULL;
   }

   return bRetVal;
}

Код, который вы нам даете, - это (почти) код C, написанный внутри файла C++. Используемая вами очистка памяти подойдет для программы на C, не использующей код / ​​библиотеки C++.

В C++ ваш код просто небезопасен и ненадежен. В C++ тип управления, о котором вы просите, реализован иначе. Используйте конструкторы / деструкторы. Используйте умные указатели. Используйте стек. Одним словом, используйте RAII.

Ваш код может (т.е. на C++ ДОЛЖЕН) быть записан как:

BOOL foo()
{
   BOOL bRetVal = FALSE;

   std::auto_ptr<int> p = new int;

   // Lot of code...

   return bRetVal ;
}

(Обратите внимание, что создание int несколько глупо в реальном коде, но вы можете заменить int любым типом объекта, и тогда это будет иметь больше смысла). Представим, что у нас есть объект типа T (T может быть int, некоторым классом C++ и т. д.). Тогда код становится:

BOOL foo()
{
   BOOL bRetVal = FALSE;

   std::auto_ptr<T> p = new T;

   // Lot of code...

   return bRetVal ;
}

Или даже лучше, используя стек:

BOOL foo()
{
   BOOL bRetVal = FALSE;

   T p ;

   // Lot of code...

   return bRetVal;
}

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

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

Alien01 wrote: Currently I am working on a project where goto statements are heavily used. The main purpose of goto statements is to have one cleanup section in routine rather than multiple return statements.

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

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

class auxNullPtrException : public std::exception {
    public:
        auxNullPtrException::auxNullPtrException()
            : std::exception( " OOM \n") {}
    };

    BOOL foo()
    {
        BOOL bRetVal = FALSE;
        try {
            int *p = NULL;
            p = new int;
            if (p == NULL)
            {
                throw auxNullPtrException();
            }
            // Lot of code...
         }
         catch(auxNullPtrException & _auxNullPtrException)
         {
             std::cerr<<_auxNullPtrException.what();
             if (p)
             {
                 delete p;
                 p = NULL;
             }
         }
         return bRetVal;
    }

Используемый в ядре Linux, goto, используемый для очистки, хорошо работает, когда одна функция должна выполнить 2 или более шагов, которые, возможно, потребуется отменить. Шаги не обязательно должны быть выделением памяти. Это может быть изменение конфигурации фрагмента кода или регистра набора микросхем ввода-вывода. Goto могут понадобиться только в небольшом количестве случаев, но часто при правильном использовании они могут быть решением Лучший. Они не злые. Они инструмент.

Вместо...

do_step1;
if (failed)
{
  undo_step1;
  return failure;
}

do_step2;
if (failed)
{
  undo_step2;
  undo_step1;
  return failure;
}

do_step3;
if (failed)
{
  undo_step3;
  undo_step2;
  undo_step1;
  return failure;
}

return success;

вы можете сделать то же самое с такими операторами goto:

do_step1;
if (failed) goto unwind_step1;

do_step2;
if (failed) goto unwind_step2;

do_step3;
if (failed) goto unwind_step3;

return success;

unwind_step3:
  undo_step3;

unwind_step2:
  undo_step2;

unwind_step1:
  undo_step1;

return failure;

Должно быть ясно, что в этих двух примерах один предпочтительнее другого. Что касается группы RAII ... В этом подходе нет ничего плохого, если они могут гарантировать, что раскрутка всегда будет происходить в строго обратном порядке: 3, 2, 1. И, наконец, некоторые люди не используют исключения в своем коде. и проинструктируйте компиляторы отключить их. Таким образом, не весь код должен быть безопасным в отношении исключений.

Оборотная сторона GOTO довольно хорошо обсуждается. Я бы просто добавил, что 1) иногда вам нужно их использовать и нужно знать, как минимизировать проблемы, и 2) некоторые общепринятые методы программирования скрыты от GOTO, так что будьте осторожны.

1) Когда вам нужно использовать GOTO, например, в ASM или в файлах .bat, думайте, как компилятор. Если вы хотите кодировать

 if (some_test){
  ... the body ...
}

делать то, что делает компилятор. Создайте метку, цель которой - пропустить тело, а не делать то, что следует за ним. т.е.

 if (not some_test) GOTO label_at_end_of_body
  ... the body ...
label_at_end_of_body:

Нет

 if (not some_test) GOTO the_label_named_for_whatever_gets_done_next
  ... the body ...

the_label_named_for_whatever_gets_done_next:

Другими словами, цель метки - не для чего-то делать, а для чего-то пропустить.

2) То, что я называю GOTO-in-disguise, - это все, что можно превратить в код GOTO + LABELS, просто определив пару макросов. Примером является метод реализации конечных автоматов с помощью переменной состояния и оператора while-switch.

 while (not_done){
    switch(state){
        case S1:
            ... do stuff 1 ...
            state = S2;
            break;
        case S2:
            ... do stuff 2 ...
            state = S1;
            break;
        .........
    }
}

может превратиться в:

 while (not_done){
    switch(state){
        LABEL(S1):
            ... do stuff 1 ...
            GOTO(S2);
        LABEL(S2):
            ... do stuff 2 ...
            GOTO(S1);
        .........
    }
}

просто определив пару макросов. Практически любой FSA можно превратить в структурированный код без использования goto. Я предпочитаю держаться подальше от кода GOTO-in-disguise, потому что он может попасть в те же проблемы со спагетти-кодом, что и неприкрытые gotos.

Добавлено: Чтобы успокоить: я думаю, что одна из отличительных черт хорошего программиста - это признание того, что общие правила не применяются.

За восемь лет программирования я много использовал goto, большая часть этого была в первый год, когда я использовал версию GW-BASIC и книгу 1980 года, в которой не было ясно, что goto следует использовать только в некоторых случаях. Единственный раз, когда я использовал goto в C++, - это когда у меня был код вроде следующего, и я не уверен, есть ли лучший способ.

for (int i=0; i<10; i++) {
    for (int j=0; j<10; j++)
    {
        if (somecondition==true)
        {
            goto finish;
        }
        //Some code
    }
    //Some code
}
finish:

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

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

Обычно единственное исключение, которое я делаю из правила «no goto» при программировании, - это выход из вложенных циклов до определенного уровня, что я столкнулся с необходимостью сделать только при работе над математическим программированием.

Например:

for(int i_index = start_index; i_index >= 0; --i_index)
{
    for(int j_index = start_index; j_index >=0; --j_index)
        for(int k_index = start_index; k_index >= 0; --k_index)
            if (my_condition)
                goto BREAK_NESTED_LOOP_j_index;
BREAK_NESTED_LOOP_j_index:;
}

Я не знаю, откуда взялась эта вещь о goto ...

На скомпилированном языке все условные инструкции (if, switch, for, while и т. д.) Разрешаются в "cmp", "jmp" или "j ??" в машинном коде (jmp IS goto).

Фактически, действительно хорошо оптимизированный код знает о лучших путях выполнения и ДОЛЖЕН поэтому использовать "goto" ... Даже лучше делать линейный фрагмент кода с goto, чем методы и вызовы, когда стек не используется ("call" = "push" + "jmp").

Нет абсолютно никаких веских причин, по которым вы не должны использовать GOTO в C++: сгенерированный код и так полон "jmp" везде.

Это проблема только в сценариях (где она часто недоступна), потому что назначение goto не обязательно интерпретируется, когда есть инструкция goto.

Первоначальный аргумент против goto состоит в том, что код сложнее проверить.

Это абсурд: Код не предназначен для проверки (или только ОДИН РАЗ): он предназначен для выполнения, чтобы он был небольшим и быстрым. Оптимизированный фрагмент кода должен избегать избыточности (путем повторного использования тех же инструкций) и избегать проверок во время выполнения (следует избегать всех исключений, не связанных с аппаратными сбоями, во время разработки, а НЕ во время выполнения).

Единственные две причины, по которым я использую goto в своем коде на C++:

• Разрыв вложенных циклов уровня 2+

• Сложные потоки, подобные этому (комментарий в моей программе):

  /* Analysis algorithm:
  
    1.  if classData [exporter] [classDef with name 'className'] exists, return it,
        else
    2.    if project/target_codename/temp/classmeta/className.xml exist, parse it and go back to 1 as it will succeed.
    3.    if that file don't exists, generate it via haxe -xml, and go back to 1 as it will succeed.
  
  */
  

Для удобства чтения здесь после этого комментария я определил метку step1 и использовал ее на шагах 2 и 3. На самом деле, в более чем 60 исходных файлах только эта ситуация и один 4 уровня вложенности - это те места, где я использовал goto. Всего два места.