Is a boolean expression as onerous as branching with if or switch?

Question

Often I convert some if statements into boolean expressions for code compactness. For instance, if I have something like

foo(int x)
{
   if (x > 5) return 100 + 5;

   return 100;
}

I'll do it like

foo(int x)
{
   return 100 + (x > 5) * 5;
}

This is very simple so no problem, the thing is when I have multiple tests, I can greatly simplify them (at the expense of readability but that's a different issue).

So the question is if that (x > 5) evaluation is as onerous as explicitly branching with it.

Wow, thats totally unreadable. [And compiles to the exact same assembly](https://godbolt.org/z/i7z95k). — tkausl, Apr 04 '19 at 00:20
What do you intend to mean by "onerous"? You say that readability is a separate issue, but I would say that the decreased readability makes the code *more* onerous. — JaMiT, Apr 04 '19 at 00:25
Yea, a bool is guaranteed to return 0 or 1, but. `100 + (x > 5) * 5` is just not right. One objective of writing code is to be clear. — lakeweb, Apr 04 '19 at 00:26
This would perhaps better express the intent: `return 100 + ((x > 5) ? 5 : 0)` — VLL, Apr 04 '19 at 08:33

score 3 · Answer 1 · answered Apr 04 '19 at 08:12

In both cases the expression (x > 5) has to be checked if it evaluates to true . And as demonstrated already, both versions compile to the same assembly even without any optimization enabled.

However, the Philosophy section of C++ Core Guidelines has these two rules you would do well to pay heed to:

P.1: Express ideas directly in code
P.3: Express intent

Though these rules cannot be enforced in anyway, adhering to them will make you adopt the version with the if statement.

Doing so will make it less onerous for those who have to maintain the code after you and even yourself a few months later.

score 1 · Answer 2 · answered Apr 04 '19 at 09:04

You seem to be conflating C++ language constructs with patterns in the assembly. It may have been viable to reason about code on this level given the compilers of the late eighties or early nineties. At this point, however, compilers apply a lot of optimizations and transformations whose correctness or utility is not even obvious to the average programmer. A very simple example is the common beginner's mistake of assuming the following equivalences:

std::uint16_t a = ...;
a *= 2;   // a multiplication in assembly
a *= 17;  // ditto
a /= 3;   // a division in assembly

They may then be surprised to find out that their compiler of choice translates these into the assembly equivalent of e.g.:

a <<= 1u;
a = (a << 4u) + a; // or even (a << 4u) | a if a < 16
a *= 43691u;

Note that the last transformation is only allowed if a is known to be a multiple of the divisor, so you may not see this kind of optimization all too often. How does it even work? In mathematical terms, uint16_t can be thought of as the residue class ring Z/(2^16)Z, and in this ring, there exists a multiplicative inverse for any element that is coprime to 2^16 (i.e. not divisible by 2). If d (e.g. 3) is coprime to 2, it has such an inverse, and then dividing by d is simply equivalent to multiplying by the inverse of d if the remainder is known to be zero. (I won't go into how this inverse can be calculated here.)

Here is another surprising optimization:

long arithsum(long n)
{
    long result = 0;
    for (long i=0; i<=n; ++i)
        result += i;
    return result;
}

GCC with -O3 rather mundanely translates this into an unrolled loop of additions. My version (9.0.0svn-something) of Clang, however, will pull a Gauss on you if you do this, and translate this into something like:

long arithsum(long n)
{
    return (n * (n+1)) >> 1;
}

Anyway, the same caveats apply to if/switch etc. – while these are control flow structures, and so you'd think they correspond to branching, this may not be so. Likewise, what appears to be a non-branching operation might be translated to a branching operation if the compiler has an optimization rule under which this seems beneficial, or even if it is just unable to translate its own AST or intermediate representation into machine code without use of branching (on the given architecture).

TL;DR: Before you try to outsmart your compiler, figure out which assembly the compiler produces for the straightforward / readable code in this first place. If this assembly is good, there is no point in making the code more subtle / less readable.

score 0 · Answer 3 · answered Apr 04 '19 at 00:32

Assuming by onerous you mean 1/0. Sure it might work in C/C++ due to implicit typecasting but might not for other languages. If that's what you want to achieve why not use ternary operator (? :) which also makes the code more readable

foo(int x) {
   return (x > 5) ? (100 + 5) : 100;
}

Also read this stackoverflow article -- bool to int conversion

Is a boolean expression as onerous as branching with if or switch?

3 Answers3