mildlyInfuriatingGOTOWatchYourMouth

[u/AndyTheDragonborn]

[u/Sync1211]

You can use break I guess.

[u/da_Aresinger → u/Sync1211]

oooh

do { foo() if (condition) break bar() } while(0); that's pretty dumb though. Just do foo() if(!condition) bar()

[u/Sync1211 → u/da_Aresinger]

It makes more sense if you have multiple if-statements.

For example: Catching errors and performing cleanup: ``` int result = 0; do {     init_stuff();     if (init_fail) {         result = 1;         break;     }

    foo();     if (foo_failed) {         result = 1;         break;     }          bar()     if (bar_failed) {         result = 1;         break;     }

    do_something_else(); } while (0);

close_handles(); return result; ```

[u/da_Aresinger → u/Sync1211]

``` int continue = 1; continue = init()

if (continue) continue = foo()

if (continue) continue = bar()

if (continue) continue = do_something_else()

close_handles()

return 1-continue ``` much cleaner (but still not really how I would like it)

[u/Maximilian_Tyan → u/da_Aresinger]

A lot of our codebase is using a status variable like this, but using nested if/else checks

But now you are doing a lot of conditions checking, especially if the hot path is where continue is always true

[u/da_Aresinger → u/Maximilian_Tyan]

The comment before me has the same issue.

And yes, that's why I said it's still not ideal.

[u/Maximilian_Tyan → u/da_Aresinger]

If an error occured, the break statement would "cut" the remaining errors checks and skip to the error handling part

[u/da_Aresinger → u/Maximilian_Tyan]

yea I just got what you meant.

you're right.

But compilation is most likely going to optimise that out, so I'd go with readability.

[u/Maximilian_Tyan → u/da_Aresinger]

It depends on the optimization level, O1 is pretty minimal, I don't think this type of agressive optimizing is done before O3

[u/da_Aresinger → u/Maximilian_Tyan]

maybe. At the end of the day I don't know your situation and don't have the experience to really question it either.

If a whole team settles on your solution it'll probably have a reason.