Conditional operator as a statement
-
@JonB said in Conditional operator as a statement:
, operator returns value to right of it, so I would expect to see 1 more than the answer to Life, The Universe & Everything :)
Gotcha! :) Operator , has lower precedence than operator <<.
@Chris-Kawa said in Conditional operator as a statement:
Gotcha! :) Operator , has lower precedence than operator <<.
Ridiculous! I do not acknowledge
<<
"stream" as a decent operator! Does that have different precedence than the only respectable<<
shift-left operator? :) -
With stream and shift operators it's like with right and left angles.
They're really the same thing (wink wink, nudge nudge). -
It is syntactically correct (just an expression of type void), but it's a case of what I would call "clever code" (not a compliment). It lessens readability and kinda hides the real action in a side effect of an operator for the sake of... yeah, being clever I guess, as it's not even shorter or anything.
Another example of this I've seen is the "clever" use of comma operator:
std::cout << calculate42(), calculate43();
Without looking it up - do you remember what gets printed?@Chris-Kawa said in Conditional operator as a statement:
It is syntactically correct (just an expression of type void), but it's a case of what I would call "clever code" (not a compliment).
I would say, in general this has several caveats:
- It works in this case (as described in the OP) because both functions return void.
- If they don't return void (but the same type), there might be a [[maybe_unused]] needed depending on compiler flags.
- If they return incompatible types this doesn't work. (This makes it a programming pattern that cannot always be applied.)
For me, it has too many caveats. It's bad for teachability (which to the C++ standards committee is important).
It is also one of the use cases for this operator that is not taught. In theory, every C and C++ programmer should be able to figure this out, but it is certainly not beginner friendly. Code is meant to be written once (or at least very few times) but read several times. This will certainly break the reading flow for programmers on every experience level because it is so unusal.
The general rule is to never user
?:
, but to use regularif
/else
instead. There are a few corner cases where this is still acceptable. This mostly has to do with initialization. It is kind of unavoidable withconst
variables (though, there is a workaround with immediately invoked lambdas):const auto myvar = someBool ? 0 : 1;
But, even without
const
we would otherwise have initialization + copy if we are usingif
/else
. The same is true for the OP example:setLabelText(docType == SW::FACTURA ? "Factura" : "Boleta");
In this case the
QString
constructor will only be called for one of the strings.To answer the initial question: I don't think this is acceptable in the broader C++ community.
-
@Chris-Kawa said in Conditional operator as a statement:
It is syntactically correct (just an expression of type void), but it's a case of what I would call "clever code" (not a compliment).
I would say, in general this has several caveats:
- It works in this case (as described in the OP) because both functions return void.
- If they don't return void (but the same type), there might be a [[maybe_unused]] needed depending on compiler flags.
- If they return incompatible types this doesn't work. (This makes it a programming pattern that cannot always be applied.)
For me, it has too many caveats. It's bad for teachability (which to the C++ standards committee is important).
It is also one of the use cases for this operator that is not taught. In theory, every C and C++ programmer should be able to figure this out, but it is certainly not beginner friendly. Code is meant to be written once (or at least very few times) but read several times. This will certainly break the reading flow for programmers on every experience level because it is so unusal.
The general rule is to never user
?:
, but to use regularif
/else
instead. There are a few corner cases where this is still acceptable. This mostly has to do with initialization. It is kind of unavoidable withconst
variables (though, there is a workaround with immediately invoked lambdas):const auto myvar = someBool ? 0 : 1;
But, even without
const
we would otherwise have initialization + copy if we are usingif
/else
. The same is true for the OP example:setLabelText(docType == SW::FACTURA ? "Factura" : "Boleta");
In this case the
QString
constructor will only be called for one of the strings.To answer the initial question: I don't think this is acceptable in the broader C++ community.
@SimonSchroeder said in Conditional operator as a statement:
The general rule is to never user ?:, but to use regular if/else instead.
Hi Simon. I always read your posts with interest. To be 100% clear, you are not speaking about using
? :
in general in its normal "expression-result" context are you? You have no problem with e.g.variable = b ? x() : y();
, do you? Only with using it as a statement,b ? x() : y();
, right? Where we are indeed all agreeing this is not a "recommended" construct.Reading through the C++ standard now I come across two apparently legitimate uses of
? :
which are surprising to me at least, and germane to this thread.First, they spend time discussing what to do when either side of the
:
is of typevoid
. Which I cannot see as usable in any context where the expression result is used (e.g. assignment to variable or in anif
condition). This only makes sense (to me) in statementcond ? voidFunc() : voidFunc2();
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
-
@SimonSchroeder said in Conditional operator as a statement:
The general rule is to never user ?:, but to use regular if/else instead.
Hi Simon. I always read your posts with interest. To be 100% clear, you are not speaking about using
? :
in general in its normal "expression-result" context are you? You have no problem with e.g.variable = b ? x() : y();
, do you? Only with using it as a statement,b ? x() : y();
, right? Where we are indeed all agreeing this is not a "recommended" construct.Reading through the C++ standard now I come across two apparently legitimate uses of
? :
which are surprising to me at least, and germane to this thread.First, they spend time discussing what to do when either side of the
:
is of typevoid
. Which I cannot see as usable in any context where the expression result is used (e.g. assignment to variable or in anif
condition). This only makes sense (to me) in statementcond ? voidFunc() : voidFunc2();
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
@JonB said in Conditional operator as a statement:
(x ? y : z) = 42;
Should remember this next time I ask for code review for a C++ commit :-D
-
@JonB said in Conditional operator as a statement:
(x ? y : z) = 42;
Should remember this next time I ask for code review for a C++ commit :-D
@jsulm
Indeed :) I took this from https://en.cppreference.com/w/cpp/language/operator_other.html, at the end of the Conditional operator sub-topic, where they give:// simple lvalue example int m = 10; (n == m ? n : m) = 7; // n == m is false, so m = 7
! :)
-
@SimonSchroeder said in Conditional operator as a statement:
The general rule is to never user ?:, but to use regular if/else instead.
Hi Simon. I always read your posts with interest. To be 100% clear, you are not speaking about using
? :
in general in its normal "expression-result" context are you? You have no problem with e.g.variable = b ? x() : y();
, do you? Only with using it as a statement,b ? x() : y();
, right? Where we are indeed all agreeing this is not a "recommended" construct.Reading through the C++ standard now I come across two apparently legitimate uses of
? :
which are surprising to me at least, and germane to this thread.First, they spend time discussing what to do when either side of the
:
is of typevoid
. Which I cannot see as usable in any context where the expression result is used (e.g. assignment to variable or in anif
condition). This only makes sense (to me) in statementcond ? voidFunc() : voidFunc2();
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
@JonB said in Conditional operator as a statement:
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
++++++++++[>++++++++++<-]>+++++. T >++++++++++[>++++++++++<-]>+++++++++++++++++. h +++++++++. a +++++. n --------. k +++. s +++++++++++++. , >++++++++++[>++++++++++<-]>++++++++++++. (space) <++++[>++++++++<-]>. I >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. h +. a +++. t ---------. e >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. i ----. t +. .
-
@JonB said in Conditional operator as a statement:
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
++++++++++[>++++++++++<-]>+++++. T >++++++++++[>++++++++++<-]>+++++++++++++++++. h +++++++++. a +++++. n --------. k +++. s +++++++++++++. , >++++++++++[>++++++++++<-]>++++++++++++. (space) <++++[>++++++++<-]>. I >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. h +. a +++. t ---------. e >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. i ----. t +. .
-
@J.Hilk
I recognise the code language in your blob! It is "brainf*ck", and I have previously done a bit of coding/playing in it! :) One of the finest, simple languages out there, I don't know why it is not used widely in real world programming ;-) -
@JonB turing completeness is all you need.
Everything else is for those nerds that are concerned with silly stuff like compute time or physical limits of memory.
Pfft
@J.Hilk
It's great. Simple, clearly documented, and no undefined behaviour. As a bonus IIRC (unless I am mistaken, haven't checked?) you cannot actually put comments into your code (unless yours work because it ignores any non-language characters?), which is also great for code writing.... -
@J.Hilk
It's great. Simple, clearly documented, and no undefined behaviour. As a bonus IIRC (unless I am mistaken, haven't checked?) you cannot actually put comments into your code (unless yours work because it ignores any non-language characters?), which is also great for code writing....@JonB No question about it.
But the perfect programming language is GulfOfMexico (previously known as DreamBerd)
I highly recommend checking it out:
-
@JonB said in Conditional operator as a statement:
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
++++++++++[>++++++++++<-]>+++++. T >++++++++++[>++++++++++<-]>+++++++++++++++++. h +++++++++. a +++++. n --------. k +++. s +++++++++++++. , >++++++++++[>++++++++++<-]>++++++++++++. (space) <++++[>++++++++<-]>. I >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. h +. a +++. t ---------. e >++++++++++[>++++++++++<-]>+. (space) +++++++++++++++. i ----. t +. .
-
@J.Hilk
I recognise the code language in your blob! It is "brainf*ck", and I have previously done a bit of coding/playing in it! :) One of the finest, simple languages out there, I don't know why it is not used widely in real world programming ;-) -
If there's a doubt there's no doubt.
That's a weird line of code that makes you double check it to be sure you understood correctly, thus it should be avoided.
@Christian-Ehrlicher said in Conditional operator as a statement:
btw: I've a similar statement in python where I sa a c++ programmer always have to thunk about it: a = 3 if b == 4 else 5
Actually I use that python ternary-if statement quite frequently, but as for using a ternary-if as a statement in c++: I would NOT do it in my code as a statement, but only as an evaluated expression, usually assigning the result.
I'm a huge fan of ternary-if, btw! I find myself preferring it in yes/no situations..
-
@Christian-Ehrlicher said in Conditional operator as a statement:
btw: I've a similar statement in python where I sa a c++ programmer always have to thunk about it: a = 3 if b == 4 else 5
Actually I use that python ternary-if statement quite frequently, but as for using a ternary-if as a statement in c++: I would NOT do it in my code as a statement, but only as an evaluated expression, usually assigning the result.
I'm a huge fan of ternary-if, btw! I find myself preferring it in yes/no situations..
@Kent-Dorfman said in Conditional operator as a statement:
python ternary-if statement
It cannot be used as a statement in Python, only as an expression. That's what we are talking about compared to C++'s
? :
. -
@SimonSchroeder said in Conditional operator as a statement:
The general rule is to never user ?:, but to use regular if/else instead.
Hi Simon. I always read your posts with interest. To be 100% clear, you are not speaking about using
? :
in general in its normal "expression-result" context are you? You have no problem with e.g.variable = b ? x() : y();
, do you? Only with using it as a statement,b ? x() : y();
, right? Where we are indeed all agreeing this is not a "recommended" construct.Reading through the C++ standard now I come across two apparently legitimate uses of
? :
which are surprising to me at least, and germane to this thread.First, they spend time discussing what to do when either side of the
:
is of typevoid
. Which I cannot see as usable in any context where the expression result is used (e.g. assignment to variable or in anif
condition). This only makes sense (to me) in statementcond ? voidFunc() : voidFunc2();
Second, they further comment on the result of the
:
being potentially an lvalue rather than the typical rvalue one would expect. This only makes sense (to me) in statement(x ? y : z) = 42;
which perhaps surprisingly is apparently legitimate.
@JonB said in Conditional operator as a statement:
You have no problem with e.g. variable = b ? x() : y();, do you? Only with using it as a statement, b ? x() : y();, right?
You are correct, I don't have a problem with variable assignment. (I tried to clarify this by the examples I gave.) Still, I would say the general rule is to not use them. You should only use them when you really need them. Sometimes there is no other language feature that could achieve the same thing, and then it is totally fine. Just don't be too smart about it.
(I'm personally a heavy user of
?:
. I have just accidentially found this 'beauty' in my source:std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv" : type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv" : "stats-" + std::to_string(year) + "-winter-mean.csv");
MIN
andMAX
are enum values.) -
@JonB said in Conditional operator as a statement:
You have no problem with e.g. variable = b ? x() : y();, do you? Only with using it as a statement, b ? x() : y();, right?
You are correct, I don't have a problem with variable assignment. (I tried to clarify this by the examples I gave.) Still, I would say the general rule is to not use them. You should only use them when you really need them. Sometimes there is no other language feature that could achieve the same thing, and then it is totally fine. Just don't be too smart about it.
(I'm personally a heavy user of
?:
. I have just accidentially found this 'beauty' in my source:std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv" : type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv" : "stats-" + std::to_string(year) + "-winter-mean.csv");
MIN
andMAX
are enum values.)@SimonSchroeder said in Conditional operator as a statement:
(I'm personally a heavy user of ?:. I have just accidentially found this 'beauty' in my source:
std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv"
: type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv"
: "stats-" + std::to_string(year) + "-winter-mean.csv");
MIN and MAX are enum values.) -
@JonB said in Conditional operator as a statement:
You have no problem with e.g. variable = b ? x() : y();, do you? Only with using it as a statement, b ? x() : y();, right?
You are correct, I don't have a problem with variable assignment. (I tried to clarify this by the examples I gave.) Still, I would say the general rule is to not use them. You should only use them when you really need them. Sometimes there is no other language feature that could achieve the same thing, and then it is totally fine. Just don't be too smart about it.
(I'm personally a heavy user of
?:
. I have just accidentially found this 'beauty' in my source:std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv" : type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv" : "stats-" + std::to_string(year) + "-winter-mean.csv");
MIN
andMAX
are enum values.)std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv" : type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv" : "stats-" + std::to_string(year) + "-winter-mean.csv");
I think it's fine you chose
? :
here.if else
would have been much longer. But just for the record I have a thing about about factoring and not repeating. I would probably have written yours as something like:var amount = (type == MIN) ? "min" : (type == MAX) ? "max" : "mean"; std::ifstream in_winter("stats-" + std::to_string(year) + "-winter-" + amount + ".csv");
:) To me this makes it clear that the "test" is simply for the word
min
/max
/mean
and everything else is the same. And the lines are not too long! -
std::ifstream in_winter(type == MIN ? "stats-" + std::to_string(year) + "-winter-min.csv" : type == MAX ? "stats-" + std::to_string(year) + "-winter-max.csv" : "stats-" + std::to_string(year) + "-winter-mean.csv");
I think it's fine you chose
? :
here.if else
would have been much longer. But just for the record I have a thing about about factoring and not repeating. I would probably have written yours as something like:var amount = (type == MIN) ? "min" : (type == MAX) ? "max" : "mean"; std::ifstream in_winter("stats-" + std::to_string(year) + "-winter-" + amount + ".csv");
:) To me this makes it clear that the "test" is simply for the word
min
/max
/mean
and everything else is the same. And the lines are not too long! -
@JonB I would have gone with a lambda function and a full switch case approach. We're dealing with enums after all, and it screams at me: "THIS WILL EXPAND TO MORE FILES!"
@J.Hilk said in Conditional operator as a statement:
lambda function and a full switch case approach
Nah....!! KISS!! :)
And for the record I wouldn't use a
switch
statement to return a simple value where there are only 2 explicit case and a default. Why write a multiline essay to pick between a couple of literal string values? Of course it's only IMHO, and each to their own....