Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Subtle Dangers of the Comma Operator (C++)

humanreadablemag.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: The Subtle Dangers of the Comma Operator (C++)

#41

Post by tempodox »

amelius wrote: post #17
jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

As another example of unexpected behavior: a, b = 10, 20; (This assigns 10 to b but leaves a untouched)

Not if you remember that the precedence of PROGN (“the comma operator”) is even lower than assignment.

Re: The Subtle Dangers of the Comma Operator (C++)

#42

Post by roenxi »

simias wrote: post #35
jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

It might be a bit extreme but the more I'm exposed to operator overloading the more I think that it's a bad idea 99% of the time. 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 sta…

> It might be a bit extreme but the more I'm exposed to operator overloading the more I think that it's a bad idea 99% of the time.

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.

Re: The Subtle Dangers of the Comma Operator (C++)

#43

Post by BubRoss »

simias wrote: post #35
jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

It might be a bit extreme but the more I'm exposed to operator overloading the more I think that it's a bad idea 99% of the time. 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 sta…

iostream hasn't had a lot of success inside C++ either. Operator overloading is one of those features that you wish for when you don't have it. Besides standard math operators, assignment also ends up playing a major role in making data structures behave well when managing resources.

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.

Re: The Subtle Dangers of the Comma Operator (C++)

#44

Post by jfkebwjsbx »

Someone wrote: post #8
jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

“there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota“ 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_b…

An optimizer can do many things until it cannot. Since you have no easy way to assert the overall performance of your program, you may end up with broken optimizations at some point in the future due to unrelated changes, pretty much non-deterministically.

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.

Re: The Subtle Dangers of the Comma Operator (C++)

#45

Post by pornel »

Someone wrote: post #7
indogooner wrote: post #3

>> The first one is that if we overload the comma operator, we need to be extra careful to cover all cases and think about lvalues and rvalues. Otherwise we end up with buggy code. Extra careful to cover all cases is when I start looking at alternatives. In this case it is not even enhancing readability. Even if you may be an excellent programmer think whether your team can be that extra careful most of the times bef…

“Extra careful to cover all cases is when I start looking at alternatives.“ IMO, an advantage of C++ is that, in well-written code, being extra careful is (mostly) limited to the implementer of code, not to its users. It would be nice if nobody would have to be extra careful, but that’s the price you pay for power, I fear.

Rust shows that you can remove most of the footguns, and keep the power with a much smaller "extra careful" surface.

For example, instead of a comma operator and its overloads, you can have tuples. Then `let (a,b) = (b,a)` works as expected. If you want weird code, you can overload `vec += (1,2,3,4,5)` with a tuple, and that's a straightforward case with no hidden gotchas.

Re: The Subtle Dangers of the Comma Operator (C++)

#46

Post by HelloNurse »

jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

The "surprise" in the article is related to a very general class of mistake: supporting type something& but not also type something&& despite that parameter type being decisive for overload resolution purposes and despite the missing function being identical to the existing one.

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.

Re: The Subtle Dangers of the Comma Operator (C++)

#47

Post by jeffbee »

simias wrote: post #35
jeffbee wrote: post #2

The example (v += 1,2,3,4,5) is neither "nice" nor "expressive". It's confusing and dumb. The reader of this code can't be expected to know what it does. And, looking at the implementation, there's not even an efficiency benefit from doing this. You'd have a more efficient and literate program with std::iota. The rest of the article isn't wrong, but it fails to establish why anyone thinks this pattern is "nice".

It might be a bit extreme but the more I'm exposed to operator overloading the more I think that it's a bad idea 99% of the time. 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 sta…

That is pretty extreme. Where would we be without assignment and comparison overloads? Or dereference?

Re: The Subtle Dangers of the Comma Operator (C++)

#48

Post by eska »

ahartmetz wrote: post #16
raverbashing wrote: post #12

Earlier quoted context omitted.

Reasonable and "C++ library" in the same line is almost an oxymoron. 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

Qt is very reasonable and the standard library also isn't too bad. Boost (some of its sub-projects) is by far the worst in making simple things complicated.

I didn't expect anyone to compliment Qt containers. Most of them are straight up not recommended for any situation because they waste memory, have unnecessary indirections that cause dcache misses, and aren't optimal for multithreading due to COW (and accidental COW due to bad APIs).

Re: The Subtle Dangers of the Comma Operator (C++)

#49

Post by ahartmetz »

eska wrote: post #48
ahartmetz wrote: post #16

Earlier quoted context omitted.

Qt is very reasonable and the standard library also isn't too bad. Boost (some of its sub-projects) is by far the worst in making simple things complicated.

I didn't expect anyone to compliment Qt containers. Most of them are straight up not recommended for any situation because they waste memory, have unnecessary indirections that cause dcache misses, and aren't optimal for multithreading due to COW (and accidental COW due to bad APIs).

This was about ease of use and simplicity of implementation. By the way, QHash's performance will be fixed thoroughly in Qt6. It is significantly faster than std::unordered_map, whose performance is constrained by an API that effectively requires a sub-optimal implementation.

https://codereview.qt-project.org/c/qt/qtbase/+/287053

Post reply on HN