Вообще желательно написать workflow так, чтобы это избежать. Но если хочется, то почему бы и нет? Главное, чтобы читаемость сильно не страдала.

Мне при некоторых ситуациях надо прекратить выполнение функции.
Выглядит примерно так:

make_something();

if (object1.error) {
  return;
}
make_next_1();

if (object2.error) {
  return;
}
make_next_2();

Вот:

make_something();

if (!object1.error)
  make_next_1();

if (!object2.error)
  make_next_2();

make_something();

if (!object1.error)
{
   make_next_1();
}

if (!object2.error)
{
   make_next_2();
}

Не?

Если после первой ошибки не выполнять make_next_2(), можно во втором if (!object1.error && !object2.error)

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

Разбей на несколько функций, duh.

Выбрасывать исключения? Но это зависит, конечно от задачи.

А вообще, если функция маленькая (<10 строк), то ИМХО можно и без структурного фанатизма - от малюсенького return'а ничего не будет. Это же не goto.

Абсолютно нормально, АПВС?

а в чем ты видишь проблему?

тут исключения бросать надо

ОЧЕНЬ желательно, чтобы функция возвращала какую-то осмысленную ошибку, а не просто завершалась. Ну или выбрасывала исключение. Потому - не очень нормально так делать.

Но причем здесь тег «с++»?
В С++ верное решение - использовать контракты а не этот сишный маразму котрый вы привели.

Я че то не увидел, что бы ТС где то спрашивал «как мне вернуть ошибку из void функции?».

А если функция нормально завершилась и ничего не должна возвращать по дизайну, так все равно делать нельзя? Как страшно жить...

У ТСа функция может завершиться не нормально. Как минимум 3 варианта завершения: object1 error, object2 error, success.

Потому, это уже проблема дизайна, о котором ТС и спрашивает.

Скоро будут спрашивать насколько нормально вываливаться из лупа брейком вместо специального флажка в условии. Или это еще не модно?

Т.е. Вы искренне считаете, что void функции в С++ использовать некошерно?

А что, если в случае ошибки ф-я должна просто отвалится (сообщение об ошибке скажем выведено уровнем ниже, или его вообще не надо выводить), так не бывает?

абсолютно нормально, если нужно - вываливайся.

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

Нормально. А почему тебе вообще пришел в голову этот вопрос?

void foo();

с помощь return;?

ИМХО — абсолютно нормально. Мало того, если функция НЕ должна ничего возвращать, то она НЕ должна ничего возвращать. Если функция должна ЗДЕСЬ закончится, она должна ЗДЕСЬ закончиться, а не прыгать на «точку выхода». Локальные ресурсы должны сами освобождаться, а не вручную. KISS.

make_something();

if (!object1.error)
  make_next_1();

if (!object2.error)
  make_next_2();

у тебя тут ДРУГАЯ логика.

можно во втором if (!object1.error && !object2.error)

и зачем нужен лишний оверхэд? Лишняя проверка только нарушает читабельность, а иногда может и сильно затормозить. Я уж не говорю о том, что не всегда ошибку можно проверить дважды. Если мы не смогли прочитать первый байт, то глупо проверять, смогли-ли мы прочитать первый байт после чтения первого, для чтения второго. Да и если не смогли, то непонятно, какой именно байт мы не смогли прочитать.

ОЧЕНЬ желательно

это НЕ сишечка. Если ты пишешь

object x = a+b*c;

то КУДА ты засунешь свой код ошибки? Методы либо вообще ничего не возвращают, либо возвращают что-то нужное, как например здесь object_b::operator*(const object_c &) const;

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

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

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

Это называется ООП и маразм головного мозга - это не лечится.

Это псевдобесполезный ООПстайл в сишке.

Гото - раз. Табличка переходов/свич - два. Запихни это дальше, аля:

make_next_1() {
if(error)
  return;
} 

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

Зачем храниешь error, что это тебе даёт? Спегети? Вылезла ошибка - юзай гото, либо прыгай на обработчик ошибки( не гото, а функцией, если у тебя есть предрассудки по поводу гото и ты слишком анскилен, чтобы его юзать) - делай что надо с этой обишибкой и возвращай на состояние до ошибки.

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

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

Я не абделён мозгом, чтобы осилить гото и ретурн. Зачем юзать ЯП, если ты не осилил его синтаксис? Скобочки для ифа с телом в один лайн юзают лалки, нету != 0 - радует.

Приводи более широкий пример, чтобы пацаны видели из чего растут ноги, а не факт того, что ноги кривые.

Нормально.

Лишняя проверка только нарушает читабельность

Нет.

Нынешняя мода целиком навязана и усиленно продвигается «корпоративными стандартами», т.е. способом нанять армию дебилов и сделать так, чтобы они могли догадаться о чем собственно код. Неудивительно, что свежая кровь повсеместно с этим сталкивается. Кстати мода эта меняется со временем, каждые пять лет меняются вопросы «нормально ли», и каждый раз я под столом от модных ответов. Старая школа — всегда срали на эти «стандарты» и впредь будем продолжать эту добрую традицию, не переживай.

#include<stdio.h>
void foo()
{

   return;

}

int main()
{

   foo();

}

dron@gnu:~$ gcc ./test.c --std=c99 -Wall -pedantic 
dron@gnu:~$ gcc ./test.c --std=c11 -Wall -pedantic 
dron@gnu:~$ gcc ./test.c --std=c89 -Wall -pedantic 
./test.c: In function ‘main’:
./test.c:21:1: warning: control reaches end of non-void function [-Wreturn-type]
dron@gnu:~$ 

Если верить этому то сейчас(с99,с11) выходить return`ом в произвольном месте нормально, а вот раньше наверное подразумевалось не писать void функций которые не отрабатывают полностью или оперировать if`ами, исключениями.

Нет.

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

где ты тут «лишние» проверки увидел?

gcc тут ругается на main() без return (хорошо в C99 и C++, плохо в C89), а не на return в foo (всегда было хорошо).

КУДА ты засунешь свой код ошибки

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

Потому объекта который бы перешёл в особое состояние немного нет. И потому либо нужно возвращать что-то, либо экзепшн.

./test.c:21:1: warning: control reaches end of non-void function [-Wreturn-type]
раньше наверное подразумевалось не писать void функций которые не отрабатывают

Смысл сообщения от тебя ловко ускользнул, и немудрено, с таким-то выводом.

./test.c --std=c99
оперировать if`ами, исключениями

Гыы

Ой я смеюся, ой смеюся.

 
static int processPostTask(CCHttpRequest *request, write_callback callback, void *stream, int32_t *responseCode, write_callback headerCallback, void *headerStream)
{
    CURLRaii curl;
    bool ok = curl.init(request, callback, stream, headerCallback, headerStream)
            && curl.setOption(CURLOPT_POST, 1)
            && curl.setOption(CURLOPT_POSTFIELDS, request->getRequestData())
            && curl.setOption(CURLOPT_POSTFIELDSIZE, request->getRequestDataSize())
            && curl.perform(responseCode);
    return ok ? 0 : 1;
}

Ущербанский стал, ущебанское неосиляторство !ok, ущербанское api у CURLRaii. Ущербнаская бессмысленная недопроверка. Как у тебя не сработать setOption()? Кастыль, ибо не осилили assert()?

Как я люблю эту вермешельку, вроде типа красивую, в обёрточке, всё ровненько, а откроешь обёрточку - говно говном.

Но тут же совершенно другая ситуация

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

Как я люблю эту вермешельку, вроде типа красивую, в обёрточке, всё ровненько, а откроешь обёрточку - говно говном.

когда-же ты нам покажешь НЕГОВНО?

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

Я объяснил объективные причины - тебе их мало? Теперь я жду твоих контраргументов и объяснений почему код хорош.

Не тебе: Да простит меня модератор - я даже не понял, как нписал это ужасное слово, а редактировать не могу.

У вашем этом C++ есть исключения

сишке
лалки
какаха
анскилен
абделён

итд итп.

Они есть и в либц, но а) они требуют больше букв, б) они тормазят. Зачем оно такое счастье нужно.

Ты хоть почитай, дорагуша, что там написано, прежде чем пороть пургу

Там есть non-local jump. Касательно тормознутости ничего сказать не могу, но если делать return, то не просто return, а с кодом ошибки хотя бы

Мужыки, а давайте обсудим тут рестарты

subj

Тормазит, тормазит особенно если ты их воткнёшь сюда.

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

Согласен с тобой, лоханулся я.

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

а) это ничего не доказывает.

б) обосрать может каждый. Даже тот, кто совершенно не понимает того, на что срёт. Мало того, тот, кто понимает, срать скорее всего не станет, разве что у него есть тоже самое, но намного лучше. Откуда вывод:

1. ты либо не понимаешь,

2. либо у тебя есть что-то лучше.

Т.к. второе по твоим словам ложно, то очевидно, что ты не в теме.

Я объяснил объективные причины - тебе их мало? Теперь я жду твоих контраргументов и объяснений почему код хорош.

нет, ты просто всё обосрал. Какие тут могут быть аргументы, кроме как насрать на твой код?

У вашем этом C++ есть исключения

есть, но не нужно их применять бездумно. Вот тебе пример: ты пишешь в СУБД, и не получается. Вот тут исключения применять НЕ надо. Может кто-то другой тоже пишет, и это вполне нормальная ситуация, надо просто чутка подождать. Исключения нужно бросать лишь в случае фатальных ошибок, а не просто так. Они(исключения) слишком дорогие.

Нормально. А почему тебе вообще пришел в голову этот вопрос?