We use this question in technical interviews (we hire compiler developers for whom this sort of esoteric knowledge is daily bread).
It illustrates one of the incompatibilities between the C programming language and the C++ programming language. In C, the result of the comma operator is always an rvalue so it's not a valid assignment. In C++, it's an rvalue reference , which can be effectively thought of as an lvalue (without going through the convoluted value category reasoning specified by the standard which will leave anyone stymied), so it's a valid assignment.
The problems come when people think "C++ is just a superset of C" and don't know what they're talking about.
This doesn't seem like an example of C++ not being a superset of C? While there's a significant difference in how the comma operator is specified between the two languages, the C++ behavior is a superset of the C behavior. The C++ behavior is only different for constructs which aren't legal C.
> In C++, it's an rvalue reference , which can be effectively thought of as an lvalue
hmm...this doesn't sound quite right? the comma operator's result in C++ is not an rvalue reference - it takes on exactly the value category of its right operand (which in this case is an lvalue)
> Unconstrained, C++ becomes legacy quite quickly (relative to simpler languages)
I wholeheartedly agree with this.
However, in my experience (30+ years now) adding those constraints is not really a big deal. Some can be automated; good CI, stuff like clang-tidy and warnings as errors etc, and some are policy; code reviews catching hard to understand code, good tests, always allowing time to update dependencies and compiler versions.
With those constraints I've found that the crappyness of c++ is never a big deal. If you don't have them... welp... best of luck to you :)
I'll never (again) willingly work for or with someone who doesn't.
> code reviews catching hard to understand code ... always allowing time to update dependencies and compiler versions
In my experience these two practices are always the first to get dropped or de-prioritised when "business needs" come knocking.
Unfortunately, I've never seen a C++ project that's managed to keep the template wizards and language lawyers away for more than a couple of years (specifically, once the original authors are gone, all bets are off). Could just be my limited and now out of date exposure, I've been out of the C++ game (happily) for a good few years now
Last four years I'm lucky enough to just work with one friend and we are following best practices that would put many a big corp to shame.
Prior to that I worked at a smallish company with 80 devs or so, 5 or 6 doing c++ and we also did a good job and management let us and encouraged us to do the right things.
Before that... yep... like you my experience was enforced shortcuts all over the place from a management who didn't have technical understanding and didn't let the professionals they hired make professional decisions which caused much more pain down the road. Almost like a debt you have to repay with interest... but technical!
We use this question in technical interviews (we hire compiler developers for whom this sort of esoteric knowledge is daily bread).
It illustrates one of the incompatibilities between the C programming language and the C++ programming language. In C, the result of the comma operator is always an rvalue so it's not a valid assignment. In C++, it's an rvalue reference , which can be effectively thought of as an lvalue (without going through the convoluted value category reasoning specified by the standard which will leave anyone stymied), so it's a valid assignment.
The problems come when people think "C++ is just a superset of C" and don't know what they're talking about.
This doesn't seem like an example of C++ not being a superset of C? While there's a significant difference in how the comma operator is specified between the two languages, the C++ behavior is a superset of the C behavior. The C++ behavior is only different for constructs which aren't legal C.
> In C++, it's an rvalue reference , which can be effectively thought of as an lvalue
hmm...this doesn't sound quite right? the comma operator's result in C++ is not an rvalue reference - it takes on exactly the value category of its right operand (which in this case is an lvalue)
[flagged]
I still use C++11 because I feel like it's a decent balance between C and C++.
How is it a better balance than C++23? What would you lose by using C++23?
Paradoxically, in greenfield it can be pretty great.
The issue then becomes your greenfield -> legacy time horizon.
Unconstrained, C++ becomes legacy quite quickly (relative to simpler languages)
> Unconstrained, C++ becomes legacy quite quickly (relative to simpler languages)
I wholeheartedly agree with this.
However, in my experience (30+ years now) adding those constraints is not really a big deal. Some can be automated; good CI, stuff like clang-tidy and warnings as errors etc, and some are policy; code reviews catching hard to understand code, good tests, always allowing time to update dependencies and compiler versions.
With those constraints I've found that the crappyness of c++ is never a big deal. If you don't have them... welp... best of luck to you :) I'll never (again) willingly work for or with someone who doesn't.
I _generally_ agree with the above, aside from:
> code reviews catching hard to understand code ... always allowing time to update dependencies and compiler versions
In my experience these two practices are always the first to get dropped or de-prioritised when "business needs" come knocking.
Unfortunately, I've never seen a C++ project that's managed to keep the template wizards and language lawyers away for more than a couple of years (specifically, once the original authors are gone, all bets are off). Could just be my limited and now out of date exposure, I've been out of the C++ game (happily) for a good few years now
You are not wrong on average.
Last four years I'm lucky enough to just work with one friend and we are following best practices that would put many a big corp to shame.
Prior to that I worked at a smallish company with 80 devs or so, 5 or 6 doing c++ and we also did a good job and management let us and encouraged us to do the right things.
Before that... yep... like you my experience was enforced shortcuts all over the place from a management who didn't have technical understanding and didn't let the professionals they hired make professional decisions which caused much more pain down the road. Almost like a debt you have to repay with interest... but technical!
For greenfield development I’ve started using the new C++ compiler rustc.
Honestly it’s such a struggle.