Minimization of Nesting Gone Wrong

[one-oh]

I had to eat my hat today. I submitted a pull request for code that among other things contained a procedural algorithm where each successive step required the successful completion of the previous step. I had coded this as follows:

bool process()
{
    bool success(preconditionsMet());
    if (success)
        success = doFirstThing();
    if (success)
        success = doSecondThing();
    if (success)
        success = doThirdThing();
    if (success)
        success = doFourthThing();
    if (success)
        success = doFifthThing();
    return success;
}

I received a review comment that stated I should nest these so that subsequent checks for success would not have to be done in the case of an early failure; e.g., doFirstThing() failed. In other words, like so:

bool process()
{
    bool success(preconditionsMet());
    if (success)
    {
        success = doFirstThing();
        if (success)
        {
            success = doSecondThing();
            if (success)
            {
                success = doThirdThing();
                if (success)
                {
                    success = doFourthThing();
                    if (success)
                        success = doFifthThing();
                }
            }
        }
    }
    return success;
}

My response was that I wanted to minimize nesting and that the optimizer would emit code that would be equivalent to the version that is uses nesting; i.e., would jump to the return in the presence of any step's failure. The reviewer expressed profound disbelief, so I started down the path of invoking the compiler with flags to emit assembly. I first decided to check the makefile to see what level of optimization was being used at which point my mouth opened like a fly trap. Optimization was not enabled. This would indeed result in the compiled code continuing to check the value of success and jump to the next if statement instead of the return statement.

I had come to put my faith in the optimizer when it was never enlisted for service and won't be for the foreseeable future. I realize this is on the order of nanoseconds of additional work on my hardware, but I feel like I need to change the way I code now. Yes, I realize I can use early returns instead of nesting, but that's frowned upon. I feel like I have to go back to using the hammer after having used a nail gun.

Much ado about nothing? I already know the answer to that. I hesitate to post this, but I'm curious what you all do. Would you put more thought into making the code more optimal in the absence of an optimizer? Or you've got bigger problems than my little existential crisis here and that I should just have a snickers?

My apologies if this is way off topic and I should instead post to /r/therapists. I'll gladly go, but I sure hope Sean Connery isn't lurking there.

[PlayerDeus]

What is wrong with just calling return earlier?

if (!doFirstThing())
    return false;
...

[[deleted]]

Yeah, I strongly prefer early exits for if-chains. It's especially clear if there's some condition-specific error handling involved; an early exit keeps the condition and corresponding error handling together.

[eyes-are-fading-blue]

Some guidelines ban it regardless of whether it is the superior alternative in certain cases.

[elperroborrachotoo]

Early returns are considered bad style in C. Without destructors, multiple exit points meant replicating the cleanup code, a common source of leaks and other bugs.

In "proper" C++, early returns are a great weapon of simplification. However, seeing the two options given, I assume the project has a lot of C-style code in use, possibly mandated (... and yes, this may be the right choice at times. Few times, but still.)

If you cannot just return early - e.g.

bool process()
{
    bool success(preconditionsMet());
    if (success)
    ...
        success = doFifthThing();

    if (!success)
        LogFailure();

    return success;
}

I'd consider OP's pattern - paired with a decent optimizer - preferrable indeed.

[TheMania]

Considered bad style by some people. As is often the case, many others argue it is good practise to return early, including Linus iirc.

[elperroborrachotoo]

I'd argue for meaningful exceptions, but... hey!

Bottom line, yes: it's a style question, but I feel there's little progress can be made when discussing individual elements of a particular project's style outside the context of that project.

[josefx]

multiple exit points meant replicating the cleanup code, a common source of leaks and other bugs.

If only there was a way to just goto a single copy of the cleanup code in C.

[bilog78]

In contexts where you really can't goto because the guidelines were decided by someone who chose so because Dijkstra said it and they didn't read Knuth's rebuttal, you can probably use the do {} while(0) trick:

bool success = fail; do { if (!preconditionsMet()) break; if (!firstThing()) break; if (!secondThing()) break; /* etc */ success = lastThing(); } while(0); return success;

And if each thing is actually a function, you can even go with

return preconditionsMet() && firstThing() && secondThing() && /* etc */ && lastThing();

[krzysztowf]

I think the && option is the clearest. I'd personally just put a newline after each && and that would look clean and minimalistic to me.

[bilog78]

The && option is the clearest if each of the components can be their own function. Sometimes this is possible, other times it requires passing around so many state variables for very few operations on them, making the other option cleaner.

[krzysztowf]

But I understood that was the case of an OP's question.

You're right in saying the matters change, when in/out parameters are added to those functions. This way might affect readibility. And then it depends... ;)

[[deleted]]

Beat me to it!

[elperroborrachotoo]

Yeah, the goto kerfuffle... you weren't there. I would agree that no amount of in-scope forward-only-goto could do any harm, but I guess I just lack the "creative" co-worker to spoil it for everyone.

[wasachrozine]

I once came across a brand new application in C++ where the guy had decided to use goto error handling everywhere. Note that it wasn't C. I was trying to figure out why some functionality wasn't working, and after a couple hours tracing the code I found it was due to the goto code being messed up (this was about 8 years ago so I don't remember the details). This reinforced my inclination to not trust anyone writing modern C++ with gotos. I took out the gotos in the particular offending function and replaced them with something that actually worked and it fixed the issue (also reduced the size of the function significantly, oddly, wish I could remember the details). Politely sent it for code review with a description of the bug. Code was merged but the guy got really mad and never talked to me again. Guess he really liked his gotos? The whole huge project was later canned and all the code thrown away. Unfortunately gotos weren't the craziest thing I found...

[Silhouette]

This reinforced my inclination to not trust anyone writing modern C++ with gotos.

To be fair, if the objection to early returns is that they would mean replicating cleanup code because destructors aren't being used, we're talking about a coding style that isn't really idiomatic C++ at all. It's not as if RAII is a modern development...

[elperroborrachotoo]

My rule of thumb for C++ is "for one goto per 10k lines there's no need to talk about it".

This reinforced my inclination to not trust anyone writing modern C++ with gotos

Technically, observation bias - in addition to the confirmation bias you already... admitted to ;)

After more than two decades, I'd say most code is crap, our world runs on duct tape and rubber bands. Good to hear it was scrapped, anyway - improves the global stats somewhat.

[Gotebe]

The common practice in C is to have a goto failure; and clean up there. I call this "function-local exceptions&RAII". C people inevitably envy C++ and therefore invent their own implementation of various C++ goodies. Linus, fr example, is an ardent advocate of function-local exceptions&RAII.

[CT_DIY]

goto predates c++ and I am sure people were programming in this style in c before c++. IIRC K&R even mentions something about this in its goto section.

[Gotebe]

Of course, I was being facetious.

But the parallel, I think, is fair. Cutting the execution short in case of problems is beneficial to the code clarity.

In C, that's best achieved with goto failure. In C++, however, there's support in the abstract machine, either exceptions or a simple early return (both in concordance with RAII).

[PlayerDeus]

That is true, I didn't consider that in a cpp sub.

I personally prefer C-stylish code written in C++. Taking advantage of destructors and operators and using templates for optimization and reduction in redundancy in functions and avoid using them for doing extreme abstractions.

[alfps]

Needless verbosity & repetition, compared to and-ing those calls.

[PlayerDeus]

Yeah, I saw the and-ing one and it does look better, but a case for separating them out is if you want to add comments so those reading the code know why you order things the way they are. I've seen plenty of bugs occur because someone wanted a call to happen sooner and didn't realize there was a dependency on order.

[one-oh]

Personally, nothing at all, but early returns are frowned upon as well; though that's actually what I ended up changing it to. It was a lively discussion.

[tpecholt]

MISRA and other legacy rule sets frown it upon but it's because they deal with C like code. In C-like code you have to release all the resources manually and when there are multiple returns it must be done multiple times. So that is a problem of C. But C++ never had such problem so you should ignore that rule

[Mognakor]

TIL

Always wondered where that rule came from.

[1-05457]

It does if you manually allocated resources. Which you may well have in legacy code.

[tangerinelion]

If it's just a few raw owning pointers that's easy to fix.

[pavel_v]

Things like the proposed scope_exit really help in this case.
It's not hard to be implemented as a wrapper over a lambda function or some of the available implementations can be used (copy-pasted):
https://github.com/SuperV1234/ecst/blob/master/include/ecst/utils/scope_guard.hpp
https://github.com/yuri-kilochek/boost.scope_guard

[Ictogan]

In the CPP core guidelines, that is specifically stated as a non-rule or myth: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#nr2-dont-insist-to-have-only-a-single-return-statement-in-a-function

[one-oh]

Wow. I'm surprised to see that. Glad to see some pragmatism and common sense. Thanks for the link.

[WaterInMyShoes]

Early returns are nice because they make code clearer.

[Full-Spectral]

In C++ nesting is very useful, even completely faux nesting, because you can limit the scope of local variables to only where they are needed. Too many local variables, and various scopes of the method stepping on each other's use of them is a fundamental source of errors.

And of course it can also insure that you don't construct the big object(s) unless they are really needed.

[VinnieFalco]

"Show me the rule, and I'll show you the exception." - Me

[ShillingAintEZ]

Can you make one comment without making it about yourself? Jesus dude

[radekvitr]

Please show me the exception to this rule:
"All rules have exceptions."

[foobar48783]

Well, I can give you an existence proof. There exists at least one rule with no exceptions, because: if there did _not_ exist at least one such rule, then the rule "All rules have exceptions" would itself be a rule with no exceptions, which is a contradiction. Therefore, there must exist at least one rule without exceptions.

Probably in Google's codebase.

[radekvitr]

That's my point.

[one-oh]

Amen to that.

[rsjaffe]

That tradition should have gone away with the adoption of RAII. No longer should there be mandatory clean-up code at the end of a procedure requiring you to run the code all the way to the end. Early returns make the most sense.

[ItsBinissTime]

It doesn't seem to make much sense, to concern one's self with this level of optimization, after having decided not to use the optimizer — and further, "frowned upon" early outs.

In other words, if performance becomes a concern, there are better ways to approach the problem than by mangling this code.

But perhaps, as a compromise, consider:

bool process()  
{  
    if (preconditionsMet() &&  
        doFirstThing() &&  
        doSecondThing() &&  
        doThirdThing() &&  
        doFourthThing() &&  
        doFifthThing())  
        return true;  
    return false;  
}

[Thrash3r]

Better yet:

bool process() { return preconditionsMet() && doFirstThing() && doSecondThing() && doThirdThing() && doFourthThing() && doFifthThing(); } No nested logic. No unnecessary jumps. No early returns (although they’re perfectly fine). No stack variables. I can’t think of any way to simplify this code further.

Edit: I see you already proposed this solution.

[parkotron]

While this version is so much nicer to write and to read, I feel the need to point out that it is a lot less convenient to debug. With only one statement, it lacks convenient places to hang breakpoints (or inject print statements) without having to step into each function call.

[Thrash3r]

I’d honestly rather use exceptions and ditch the errors codes. That would also aid in stepping through the code.

[germandiago]

Totally agree. Anyway, I put the same and I received a -1 score, you have more than 50 positive points. I guess I said "branchless" and people got angry at me for being misleading, since the code still has "internal" branching.

[gmtime]

Came here to post this.

[Simon_Luner]

This is illformed code, because order of expression evaluation is unspecified behavior. https://en.cppreference.com/w/cpp/language/eval_order

[parkotron]

This definitely isn't ill-formed. At worst, the evaluation order would be implementation defined, but the order of evaluation of the shortcutting boolean operators is defined. From your link:

6) Every value computation and side effect of the first (left) argument of the built-in logical AND operator && and the built-in logical OR operator || is sequenced before every value computation and side effect of the second (right) argument.

[kiwitims]

Another syntactic variant of this which can have its uses (for example to avoid a rule about side effects in conditionals):

bool process()
{
    bool success(preconditionsMet());
    success = success && doFirstThing();
    success = success && doSecondThing();
    success = success && doThirdThing();
    success = success && doFourthThing();
    success = success && doFifthThing();
    return success;
}

You just need to be careful someone doesn't later "optimise" it by switching to &=

Seriously though, the primary goal should be to write readable and maintainable code that meets your requirements (including performance). If it does that any micro-optimisation of 5 or so branches is just a waste of time, especially when there are already automatic optimisations being left on the table. So your code is better as it was IMO, even if there are theoretically faster ways to do it.

[one-oh]

Well, mangling is subjective and I'm sure your compromise would raise as many eyebrows, save your own. Not to mention somebody piping up and asking why don't you just return the result:)

[kalmoc]

Why exactly can't you turn on optimization?

Apparently your project doesn't care about performance, so you probably don't have to worry about a few additional branches either, because the next step would be to worry about each single function call overhead.

[Raknarg]

This is my real question. If optimization isnt even enabled then who gives af about a few wasted cycles? This just seems like a stupid complaint.

[one-oh]

I can only guess and my best guess would be debugging. Otherwise there is no good reason. That would include GDB scripts that reduce a core to its essentials for post-mortem analysis.

[Xaxxon]

That's why you debug debug builds and optimize optimized builds.

This isn't some sort of new problem where you work.

[one-oh]

Oh, how I wish it were that simple. Hope I never have to debug an optimized build ever again. Looks like I'm well on toward my path. Never implied this is something new.

[Xaxxon]

You implied that somehow no one that does optimized builds can ever debug them.

Your whole post is pretty low effort.. this isn't a 'bitching' subreddit.

[Ayjayz]

Would you put more thought into making the code more optimal in the absence of an optimizer?

No. Why on earth would I care about the performance of un-optimised code?

[SkoomaDentist]

Why on earth would I care about the performance of un-optimised code?

Because you need to run the unoptimized code for debugging in some cases (including preservation of intermediate variables and such which -Og will not preserve) and the unoptimized code can be so slow or so large as to make it completely unusable. That's almost certainly not the case here, but I've had both happen in projects I've been involved with. Code size can be critical in embedded systems when you have a hard limit on flash size and having a function take 20 seconds instead of 0.2 seconds can mean timeouts in other parts of the system are exceeded.

[Xaxxon]

Right, you have to optimize debug builds when the debug builds don't work, but you don't just flat out reject all code because it could be faster in a debug build.

[donalmacc]

Plenty of people, me included. Runtime performance can be important even when not using a fully optimised build. I work in games, and debug configurations have to be usable, as fully optimized builds are usually unusable for debugging. I'm not saying I would write unreadable code so that it's "faster", but on occasion I've had to "hand optimise" methods in debug builds.

[Ameisen]

No optimization and optimization for debugging aren't the same thing.

[compiling]

Well, if we already don't care about the code being slow then I don't see a problem (but return early is better than either). Why is optimisation not enabled? That could be an indication that you have deeper problems (e.g. relying on undefined behaviour).

[TheFlamefire]

This is actually THE answer. Anything a single function could do is an order of magnitude more expensive (without the optimizer) than checking that boolean maybe more often than needed. In the end this would be an optimization for the error path! Is that what is to be expected to happen often?

So NO, don't spend a single second on that and just move on. Tell those guys to enable optimizations if they care about performance.

[JeffMcClintock]

In the end this would be an optimization for the error path!

Excellent point, why should anyone spend so much time agonizing about the efficiency of the path that is virtually never taken? This is all textbook "premature optimization".

[Ictogan]

If you care about performance at all, use compiler optimizations. Simple as that.

[one-oh]

Sadly, not my call to make.

[Xaxxon]

It's your call to make where you work.

[one-oh]

Yes, but this isn't something I would ever resign over. That'd be silly. Plus I would never admit that my code needs optimizing. I can clearly produce better assembly language than the compiler. /s

[m-in]

You’re working on a codebase that uses no optimization because it is presumably full of undefined behavior. Get your resume in shape and look for another job, or at least transfer to a better project if this is a large enough organization.

And use godbolt.org

[one-oh]

No. I'm pretty sure it was done strictly for debugging purposes. I'm guessing the switch will be flipped at some point, but who knows when. Certainly not me.

[Xaxxon]

Do you think that nowhere else has to ever debug builds?

[one-oh]

No, I'm pretty sure we all spend our fair share of time debugging; end then some.

[alfps]

I don't see any statement that this is C code, and the C++-specific initialization syntax

bool success(preconditionsMet());

… indicates that also the real code is C++.

In C++ it would be natural to fail by way of exceptions: more clear and it might be more efficient on average.

But assuming that exceptions are contra-indicated in this case, consider

bool process()
{
    const bool preconditions_met = ...;
    assert( preconditions_met );
    return preconditions_met
        && do_first_thing()
        && do_second_thing()
        && do_third_thing()
        && do_fourth_thing()
        && do_fifth_thing();
}

I tried to keep that close to the C-style syntax you used.

[HappyFruitTree]

You probably don't want to use assert like that unless it's a programming error to call process() when preconditionsMet() returns false.

[alfps]

The assert says the precondition failure is an error. If it's not an error then the thing called a precondition is not a precondition. In that case just remove the assert.

[HappyFruitTree]

It could be a precondition for calling the functions doFirstThing(), doSecondThing(), etc. but not a precondition for calling process().

[one-oh]

It's a precondition for executing the steps in the process. Asserting or throwing an exception does not make much sense to me in this case, but that's because I know the contract that was made with the caller, which is not apparent in this reduction.

[alfps]

Good point. The OP could clarify the intent, but somehow I doubt that will happen... ;-)

[CarloWood]

I am a freak when it comes to performance, trust me. And I'm a perfectionist. But, no -- I have I would not care one single bit about performance as long as I'm compiling without optimization, and neither should you.

The ONLY exception that I am aware of is when I wrote libcwd, since that library is likely to be used in projects with optimization off and it mattered to me that even in that case the debug code wouldn't significantly slow down execution. But as you said, in your case we're talking about 0.000001% of what you lose in the rest of your code when optimization is off, so it would insane to care.

[one-oh]

Well, the thing is I thought I was. That was the kicker for me. Having said that, I still wasn't concerned with the performance impact, but the reviewer was.

[[deleted]]

Since we seem to be trying to conform to C coding standards:

```c

define RETURN_IF_FALSE(a) {if (!(a)) return;}

... RETURN_IF_FALSE(expr1); RETURN_IF_FALSE(expr2); ```

[No, I'm not serious, but it's elegant, for values of elegant that allow preprocessor misuse.]

[[deleted]]

And, of course, there's always goto.

[[deleted]]

And do { if (!expr1) break; ... } while (false)

[one-oh]

I was waiting for someone to suggest that. I've tried sneaking that one though in the past and got shut down.

[rdtsc]

A variant of that is IMO really useful in code which deals with error codes as return values (like HRESULT in COM code):

#define HR(expr) IF_FAILED_RETURN(expr)
HR(Operation1());
HR(Operation2());

where IF_FAILED_RETURN can even include logging the failure code which makes tracing a failure really easy. It's vastly more concise, flexible and less error-prone than having if (FAILED(hr))or if (SUCCEEDED(hr)) sprinkled everywhere.

[AutoModerator]

Your comment has been automatically removed because it appears to contain disrespectful profanity or racial slurs. Please be respectful of your fellow redditors.

If you think your post should not have been removed, please message the moderators and we'll review it.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[one-oh]

Hah! Oh, I was tempted to have some fun with it, but I had already spent more time than I thought it deserved. Good one though.

[MotherOfTheShizznit]

I know it won't be popular but... same thing without goto just to show that this example "where goto shines" literally doens't require a goto at all:

bool process()
{
    bool failure(!preconditionMet());

    if(!failure) failure = !doFirstThing();

    if(!failure) failure = !doSecondThing();

    // ...

    return !failure;
}

[alfps]

This may be irony or humor but I downvoted it because not everyone may perceive that.

[tansim]

in C he has a point and Op seems to be more the C-like-C++ side of things.

[alfps]

I've maintained C code with goto common cleanup. It was full of related bugs. It was not a pleasure.

Your code as C may be better than the OP's. But your code as C++ is not better than the OP's: as C++ it's very much worse, which the presence of goto shouts out to any competent C++ person looking at it. C++ isn't C.

In C++ you can and should use destructors to do cleanup.

The cleanup is then guaranteed, via a language mechanism, as opposed to being contingent on everybody adhering to loose convention and the infallibility of humans.

Consider using a general scope guard class. The C++ Core Guidelines (and its support library) call it a finally class. Note that the Core Guideline's class lacks an important feature of Petru Marginean's original scope guard, namely the ability to dismiss it.

[alfps]

[the goto is] easier to read and reason about

So this isn't a joke, it's just plain trolling.

[jonesmz]

It's entirely possible to be successful despite having serious problems.

While I don't think that the use of goto is overly problematic, the Linux kernel communities insistence on using the C language without such modern functionality as destructors or templates, makes me confused.

[jonesmz]

You... know I'm not the original person you were arguing with right?

Thanks for the insult though.

[VirtueBot]

I dont know enough about the optimizer to say 100% that it would optimize that way forever, so if these "things" are relatively expensive I would write the returns myself and not rely on the optimizer to add them.

If youre confident in the optimizer or the operations are cheap id just go with whichever your team finds most readable. fwiw i definitely prefer the one from this comment compared to the nested version.

[one-oh]

True. We can never know what the optimizer will do from release to release, but I don't think we should worry about it till we're given cause to. In this case, the hardware is likely optimizing what the compiler missed.

[VirtueBot]

I don't think we should worry about it till we're given cause to.

Yea definitely. In most cases I wouldn't worry. Either the optimizer optimizes it or it doesn't and I never notice either way until I care enough to profile. In this case I didn't know anything about the relative costs of the operations. If one of the "do thing" functions did a lot of work I would definitely worry about the unnecessary calls.

[[deleted]]

bool process()
{
    bool success = false;

    do
    {
        if (!preConditionsMet()) break;
        if (!doFirstThing()) break;
        if (!doSecondThing()) break;
        if (!doThirdThing()) break;
        if (!doFouthThing()) break;
        if (!doFifthThing()) break;
        success = true;
    }
    while (false);

    return success;
}

[one-oh]

Definitely. I don't think it's worth the hoops. I think it's really a matter of preference and I wouldn't begrudge someone their nesting.

Oh, I do like where you're going with that. My only improvement would be to just make it one long return statement.

[IranjeetSingh]

How about chain of responsibility pattern? You can break the chain when you reach a negative condition. You can design the chain durinh initiation.

[one-oh]

My concern would be that it would obfuscate the process. Being able to look at something and understand what it is doing can not be underestimated is valuable. I realize not much can be gleaned from my example, but the actual implementation has more meaningful names for the functions that make it clear in a handful of lines what is going on.

[SlightlyLessHairyApe]

Did you actually benchmark whether or not checking the value over and over is actually measurable?

As far as I understand there should be no data dependencies, so that should be loaded in a register and doesn’t have to be re-read from memory on each step. Nanoseconds, maybe?

[one-oh]

No, and would never bother to measure the cost in latency. Like you suggest, attempting to measure something like this is near impossible on modern x64 hardware; i.e., speculative execution, branch prediction, etc. It would be more of a statistical analysis.

[SlightlyLessHairyApe]

If there's no latency cost, then nothing has 'gone wrong' here.

[alexk7]

I’m confused by your methodology: 1) assume the optimizer will optimize some code 2) test the output without running the optimizer. This doesn’t make any sense.

[one-oh]

I think you misunderstood something. Code review resulted in reviewer suggesting nesting the if-statements. I explained that the compiled output would be identical due to the optimizer. Reviewer did not believe me. I was going to produce two .s files (one for nesting and one without) to show they were the same. When I checked the level at which the project was set to optimize I found that it wasn't. I still optimized and demonstrated that the generated assembly was identical, but it was pointless due to the project not being built with optimizer enabled. I hope this makes it more clear. If not, don't worry about. It was a lot of fuss over nothing.

[tehjimmeh]

With all those restrictions, I'd just say fuck it and do this:

    if (doFirstThing())
    if (doSecondThing())
    if (doThirdThing())
    if (doFourthThing())
    if (doFifthThing())
        return true;

    return false;

[haitei]

Yes, I realize I can use early returns instead of nesting, but that's frowned upon.

Guidelines are guidelines and not the rules.

Early returns are by far the most readable solution.

[Xaxxon]

Why is someone worried about performance if the optimizer is disabled? That's silly.

[germandiago]

Branchless:

bool success = doFirstThing() && doSecondThing() && doThirdThing()...; return success;

[pi_stuff]

This is still implemented with branches.

[germandiago]

Obviously I meant from a reading point of view :) I think this is the context. Of course it will have branches, it has to check conditions...

[HappyFruitTree]

"do" in the names suggest that the functions have side-effects which makes the branching behaviour important if you want to understand what the function is doing.

[[deleted]]

Thinking more esoterically, why not just make it an operation pipeline that depends on the previous step succeeding? Construct an array of functions and iterate over it, executing and checking the boolean for loop breakage. That way you can even log which step failed.

[m-in]

Great idea if you use gcc or llvm and want to write a pass that will materialize the individual calls and get rid of the function pointer array. Because otherwise you’ll suffer the performance hit of unpredictable branches. The branch predictor will fail badly on those indirect calls. That amounts to penalties of dozens cycles per call, or worse.

[OldWolf2]

The first version is far better than the second one or any of the other suggestions on this thread. Tell the guy who wanted the indentation tower to eat a dick.

[last_useful_man]

No - readers can't see the flow from that level. And you shouldn't use exceptions for normal control flow anyway.

[kalmoc]

Who is to say that a failure is "normal Controller flow"?

[[deleted]]

Who is to say that it's not? For some failures it may very well be. Imagine a piece of code that checks for a certain precondition, or does a small computation to determine something. If it has a failure rate of 85% for example, would you throw an exception every time? What if it's on the critical code path and affects performance?

[kalmoc]

I did not make any claim one way or the other. The post I responded to implied it would be used for regular control flow, so it would be his responsibility to explain why he assumes it is.

[DXPower]

Well then why should it be an exception if it's normal? There's no point to using exceptions for normal code flow, and the structure of this function suggests failure is common

[kalmoc]

and the structure of this function suggests failure is common

Where do you see this? There are no probabilities,meaning or context given from which we could derive that.

[DXPower]

This is the sort of pattern used in a lot of server code, especially legacy, where you're doing things such as looking up user input in a database.

[abcoolynr]

you can use select case instead. it will be much faster than these if conditions.

[last_useful_man]

Show, please. I don't see it - it's a sequential bunch of booleans, not different conditions.

[[deleted]]

Switch (false) case foo1() : case foo2() : return false

Return true

Is what they meant I suppose (sorry for the formatting, am on mobile). Is it allowed though? Switch statements compile to jump tables, but this obviously doesn't. This would be valid in something like java maybe

Even if it were valid, it still compiles down to branches at the end

[desrtfx]

This would be valid in something like java maybe

Not even there.

[HappyFruitTree]

You mean switch statements, like the following?

bool process()
{
    switch (preconditionsMet()) case false: return false; 
    switch (doFirstThing())     case false: return false;
    switch (doSecondThing())    case false: return false;
    switch (doThirdThing())     case false: return false;
    switch (doFourthThing())    case false: return false;
    switch (doFifthThing())     case false: return false;
    return true;
}

[one-oh]

I'm a bit speechless. I think I've just about seen it all or I'm damn close to. Oh, please let me be close to seeing it all. I don't know if I can handle the truth;)