стиль обработки ошибок

Вполне. Щас пример приведу, где такое есть

Я ради интереса спрошу: а перед return true; память освобождать кто-нибудь будет?

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

Я бы переписал без Goto

ну функция например и должна была память нагенерить и настройки произвести

а представь сложную функцию - с кучей вложений ...

Все равно это можно переписать без goto. Либо грамотно располосовав на функции, либо через цепочку return`ов.

http://pastebin.com/rwG1keaS

Вот похожее в DragonflyBSD

Не верь!)

Можно что угодно, например наоборот: написать всё только с помощью goto. Зачем?

Зачем?

С goto код похож на макаронную фабрику.

Где фабрика в примере ТС или моем?

http://ru.wikipedia.org/wiki/Спагетти-код

В примере ТС, как минимум, перекрыщиваются пути по goto, см. http://ru.wikipedia.org/wiki/Спагетти-код

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

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

а так - весь откат этой типа «транзакции» осуществляется в одном месте

это всё вносит оверхед

тут гото не для нормальной работы - а для обработки исключений (ошибок)

Все метки у него идут на конец и никому не мешают. Согласен, что goto надо не часто, но goto-фобия - это плохо.

Кстати, треды такие возникают тут весьма часто. Точно сказать не могу, так как сам нечасто тут сижу

что такое хороший стиль - решаешь ты сам. и никто другой

Таки всё точно сказано

функция превращеться в этакий счетчик - где каждая проверка - это типа +1 к стадии выполнения
как счетчик достигнет вершины - функция выполнена - трназакция завершалиась
а если нет - то начинаеться откат изменений - и откат идет от той стадии выполнения - до которой увеличился счетчик

вот только в твоем случае могут быть утечки.

ну а это уже дело кода в откатной части функции

я сужу по приведенному примеру. если используются goto, return должен быть один

ретурнов немогет быть один
он бывает хотябы
return true и return false

посмотри на javascript - вот там макороны и без goto клепают.

а вообще 1 2 goto в функции это ничего. Ты просто никогда не писал код на QuickBasic

Лучше в C все равно не сделать. Избавляться от goto ради избавления от goto — детский сад.

return true и return false

int ret = 0;
...
ret = 1;
...
return ret;

В ядре так часто делают. Им можно, kernel кодеры работают в gods mode :)

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

предлагаеш ради этого делать еще один гото ? :)

Выбирай: дублирование кода в каждом обработчики или goto в конец функции. Где больше «макаронная фабрика?» Второй случай — это такой try-catch для C. Смущает слово «goto» — можно скрыть макросами или заменить на do-while-break.

Правильно ananas сказал: return должен быть один.

Тогда уж первый return true; выкинь, а в конце функции напиши что-то типа:

return (check) ? false : true;

предлагаеш ради этого делать еще один гото ? :)

func(){
    res = 0;
    .....
    p1=malloc();
    .....
    if(check) goto RE_0;
    .....
    .....
    p2=malloc();
    .....
    if(check) goto RE_1;
    .....
    res = 1;
RE_1: free(p2);
RE_0: free(p1);
    retuen res;
    }

?

а если эти два блока памяти должны быть остаться ?

return (check) ? false : true;

никогда не понимал, зачем так делают: почему не просто

return (check)

предлагаеш ради этого делать еще один гото ? :)

нет. предлагаю говнокод преобразовать в элегантное

int func(void){
    int ret = 0;
    .....
    p1 = p2 = NULL;
    .....
    p1=malloc();
    .....
    if(check) goto RE_0;
    .....
    p2=malloc();
    .....
    if(check) goto RE_1;
    .....
    ret = 1;
    .....
RE_1: 
    free(p2);
RE_0: 
    free(p1);
    return ret;
}

Лучше делать как-то так...

struct {
   void *p1;
   void *p2;
 ...
} my_object;

void func (my_object *me) {
 
 if(!_func(me)) {

   /* запускаем деструктор, его можно унести в отдельную ф-ю */
   if(me->p1) free(me->p1); /* и т.п. */
 }


bool _func(my_object *me) {
    

     me->p1 = malloc(...);

     /*бла бла бла */

    if(check) return false;


    /* бла бла бла */

    return true;
}

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

Я подстраивался под содержимое кода ТСа. У него там и true, и false присутствуют. Сам никогда так не писал. «С детства» приучен, что «не ноль» - это true. :)

так лучше

func(){
    bool result=FALSE;
    .....
    p1=malloc();
    .....
    if(check) goto RE_1;
    .....
    .....
    p2=malloc();
    .....
    if(check) goto RE_0;
    .....
    result=TRUE;

RE_0:  free(p2);
RE_1:  free(p1);
    return result;
}

false и true - это с++ синтаксически верные константы. в с они могут быть define-ами и иметь свой сакральный смысл

те же яйца, утечки

опередил :)

можно - но тогда деструктор должен точно знать или анализировать степень изменения состояния выполнения функций
если это не один обьект - а общая среда программы

а в чем принципиальное отличие от твоего примера, а то может я сонными глазами не вижу :) И где утечки там?

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

они могут быть define-ами и иметь свой сакральный смысл

а вот такого никогда не видел

И где утечки там?

return перед free

Странно. Достаточно часто встречается. Во всяком случае в моей практике в чужом коде видел десятки раз. Сам так предпочитаю не делать.

а вот такого никогда не видел

я тоже. но вероятность есть

при чем тут откат состояния?