Conditional operator as a statement

[JonB]

@J.Hilk Fair enough! But what is "an Undertale rash", Google talks about it in some game but that's it?

[J.Hilk]

@JonB Undertale is a game that’s kind of infamous among programmers for having huge, messy if-else chains in its code.
So when I say “Undertale rash,” I mean I get an allergic reaction to code that looks like that

[Chris Kawa]

I really don't like lambdas used like this. Pack it in a function and you first have to go to the end of it to see what it's doing and then go back up to see how it is doing it. Have 2 or 3 of those in a function and the flow is completely ruined - you have to jump around and scroll multiple screens up and down to figure out what's going on.
I'm with @JonB on this - readability doesn't mean verbosity. Often fewer words express the intent better than paragraphs of syntax with sprinkles of what the code is actually doing.

[JonB]

@J.Hilk said in Conditional operator as a statement:

So when I say “Undertale rash,” I mean I get an allergic reaction to code that looks like that

Not knowing about the game or its code, I wondered if you intended "Undertail rash" and were thinking of a rash on your private back bits! :)

[Kent-Dorfman]

So which is more appropriate then? I know my choice.

Gas myGas(LOW_OCTANE);
if (engine.IsHighCompression()) { myGas = Gas(HIGH_OCTANE); }

or

Gas myGas;
if (engine.IsHighCompression()) { 
    myGas = Gas(HIGH_OCTANE); 
} else {
    myGas = Gas(LOW_OCTANE);
}

or

Gas myGas(engine.IsHighCompression() ? HIGH_OCTANE : LOW_OCTANE);

[JonB]

@Kent-Dorfman
The ? : one for me. If other people care I'm guessing they would be the same.

[J.Hilk]

@Kent-Dorfman

3 Simple, readable, no unnecessary object construction or copy/assignment stuff. I would only question why it's not const.

Wouldn't change 1. If I encountered it in a code base, but it's not my style

2 urgh, there would need to be some more context in the function before I approved it in a code review :D

[GrecKo]

Pattern matching could help (latest proposal : P2688R5)

Example usage: https://godbolt.org/z/zqenMsEch

[Kent-Dorfman]

@JonB @J.Hilk
Yeah, my decreasing order of preference too is 3, 1, 2...I'm guilty of (1) quite freqently during freeform though to text coding. as far as constifying everything...I'm lazy, and it stifles creativity ;^)

[SimonSchroeder]

I would expect to see 2 from C++ beginners (and maybe even intermediates). The variable declaration does not look like it is doing something. (And it behaves differently than built-in types because those stay uninitialized (up until C++26) when declared like this. Does anybody know if [[indeterminate]] would avoid calling the constructor?)

I am working in a context where performance matters and I'm highly aware of unnecessary work. Option 1 would initialize once and maybe do a second assignment. Option 2 would initialize once and definitely assign afterwards. Option 3 only has a single initialization. I would go for option 3. (Even more pedantic: in option 2&3 it is not just an additional assignment, but also an additional call to the constructor (and destructor). At least use a setter in these cases.)

Now, I'm really curious if as of C++26 this would be as performant as option 3:

Gas myGas [[indeterminate]];
if (engine.IsHighCompression()) { 
    myGas = Gas(HIGH_OCTANE); 
} else {
    myGas = Gas(LOW_OCTANE);
}

If it is, we might rethink what the most readable and thus proper answer should be.

[Chris Kawa]

@SimonSchroeder Constructors might have side effects beyond object initialization (think logging, caching etc.). Compiler can't skip them (it would set world on fire at this point).
[[indeterminate]] is for cases where there's no constructor to call (e.g. int x; or char[SIZE] y;).
Given how compilers handled this case perfectly well up to this point, even providing warnings and means to silence them, I'd guess the only thing [[indeterminate]] will affect is better diagnostics and a "hook" for tools like static analyzers. I doubt it will actually affect code gen much (but I've been wrong before, so we'll see).

Edit: I'm not really a fan of this new attribute. From a talk about it I remember a mention that compilers will start filling uninitialized variables not marked with it with a detectable pattern, for the sake of safety (covering secrets in uninitialized memory). That means existing software that uses this will get slower just by recompiling, which is very not in the spirit of C++. Idea is ok, but that execution is awful.

[SimonSchroeder]

@Chris-Kawa said in Conditional operator as a statement:

I doubt it will actually affect code gen much (but I've been wrong before, so we'll see).

Starting with C++26 [[indeterminate]] will be the old (current) behavior. Without it we are in the area of the newly defined "erroneous behavior". What this means in this context is that a variable without the [[indeterminate]] attribute (and without initialization) will be initialized starting from C++26, at least before it is first read from (if the first read happens before the first write). Depending on how much the compiler can prove initialization might always happen ("always" for a lazy compiler). I agree that in most cases the most common compilers will generate the same code. (Everything else will be a bug in the original code.)