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.
> 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!
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.
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!