The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".
The only use that seems absolutely in my opinion is when the overload is absolutely transparent mathematically, for instance to implement geometrical transformations on a Matrix class.
That works because in this case you don't actually end up with "custom" behavior, you just expand the standard and well understood notation of the language by plugging the standard and well understood mathematical notation for matrix operations. Anybody who understands this mathematical notation will be able to understand what the code does without additional context.
Anything beyond that is just asking for trouble IMO. It's basically code obfuscation.
Of course C++ has precedent for that sort of insanity, especially with the IMO absolutely bonkers use of the bit shift operators for... input/output processing. A notation that you'll note hasn't had a lot of success outside of C++.
Quite a moderate position in practice. There are a substantial number of programmers who enjoy being able to tell what basic syntax does from memory without having to cross-reference documentation and source files.
And as you allude to, the example in question isn't a sum; it is an append. It would be far more appropriate to have an a = append(a, {1,2,3,4,5}) style construct. Or something with pointers if efficiency is important. Or construct the vector inline in older versions of C++. The += should be reserved for actual vector summing.
This whole article stands as a reminder that C++ is a remarkable language, and is starting to make up a lot of ground on achieving feature parity with Common Lisp.
It can be abused but most of the time is extremely convenient. Iostream and boost set a terrible example however. Boost especially goes into the deep end on templates, operators, crazy dependencies, unacceptable compile times etc. It really isn't fair to judge modern C++ on boost. Instead of being batteries included, boost is now more a last resort.
Overloading the comma operator doesn't cause any particular danger, it merely provides a mildly unfavourable situation in which an unnecessary mistake is possible: there's "threat" of the default comma operator that does something completely different, it's not very obvious whether type something or something& or something&& is considered, and the involved overload resolution rules are somewhat lawyer-grade.
v += 1.500
may be just as confusing.
a, b = 10, 20;
(I find this the most weird thing about C/C++ culture: they are so proud it is static typed, yet oblivious to all the other problems and traps/memory unsafety/undefined behavior/etc.)
#include <tuple>
#include <iostream>
std::tuple<int, int> divide(int dividend, int divisor) {
return {dividend / divisor, dividend % divisor};
}
int main() {
using namespace std;
auto [quotient, remainder] = divide(14, 3);
cout << quotient << ',' << remainder << endl;
} auto [quotient, remainder] = divide(14, 3);
std::tie(quotient, remainder) = divide(14, 3);
This shows the kind of (imho) "ugly hacks" the C++ committee had to make to cover up the historical mistake with the comma operator.
(a, b) = (10, 20)
Contrast this to:
a, b = 10, 20
a, (b = 10), 20
I never liked the comma operator, even in C. It's that kind of thing that "looks nice" at first but it is confusing in the end. It's not syntactic sugar, it's syntactic raisins.
v += [1, 2, 3, 4, 5] makes sense to me
or, for a less ambiguous meaning
v.extend([1, 2, 3, 4, 5]);
is just fine.
I don't think it makes sense to view comma as an operator.
V+={1,2,3,4,5};I would pick a different syntax, too, but this is more flexible than std::iota. You can do v+=a,b,c, for example.
I also would think any decent compiler would completely optimize away that appender instance, making it quite efficient for short lists of items (for longer lists, compiling a push_back call for each item would get inefficient, memory and cache-wise. I don’t see a compiler converting that into a loop)
In addition, more templates and more types means way less compiler throughput. That is why major parts of Boosts are avoided.
Not to mention human throughput too.
> compiling a push_back call for each item would get inefficient, memory and cache-wise?
That depends a lot on what you are doing.
By the way, if you are dealing with tons of constants in your code, then it usually means the design of the application is likely inflexible and a code smell overall.
I'm intentionally using a weak argument here...
We like to complain about Java but the C++ guys went all in and apparently can't seem to write a simple array without inheriting from at least 3 primitives and using a couple of templates.
Yes please tell me how you follow the "SOLID" principles when this is as frail as a house of cards