4 ms·
> Fight me. OK. Operator overloading is a useful feature that saves a bunch of time and makes code way more readable. You can quibble whether operator<<() is
by AndrewStephens 3y ago
> Fight me.
OK.
Operator overloading is a useful feature that saves a bunch of time and makes code way more readable.
You can quibble whether operator<<() is a good idea on streams and perhaps C++ takes the concept too far with operator,() but the basic idea makes a lot of sense.
string("hello ") + string("world");
complexNumber2 * complexNumber2;
for (int i : std::views::iota(0, 6)
| std::views::filter(even)
| std::views::transform(square))
someSmartPtr->methodOnWrapperClass();
- coldpie 3y agoAll the things you wrote could be about as easily written & much more easily read without operator overloading. Operator overloading only allows programmers to feel "smart" for doing a "clever" thing, to the detriment of future readers. string("hello ").append("world"); complexNumber2.mult(complexNumber2); // wtf is even going on with this one in your example? have these people never heard of method chaining? for(int i : std::views::iota(0,6).filter(even).transform(square)) (*smartPtr)->methodOnWrapperClass(); That's all about the same verbosity, it's much more clear to the reader even if they're unfamiliar with your codebase, and dropping operator overloading eliminates the "clever" option to do stupid crap like divide file path objects together.
- AndrewStephens 3y agoWould you advocate getting rid of operators altogether? 3.times(2).plus(7) Some things just lend themselves to being expressed in terms of simple operators. (*smartPtr)->methodOnWrapperClass(); That is still using the overloaded SmartPtr<>::operator*() method. I understand the viewpoint that operator overload is syntactic sugar for things that can easily be done another way, I just disagree that costs outweigh the benefits.
- coldpie 3y ago> Would you advocate getting rid of operators altogether? Of course not. It makes sense for built-in types, as everyone reading the code can be assumed to know them. > That is still using the overloaded SmartPtr<>::operator*() method. Good catch ;) > I just disagree that costs outweigh the benefits. Yah, I think that's the disagreement. My feeling is there's a teeny, tiny handful of appropriate places for it (almost entirely math) and it opens up a pandora's box of terrible decisions that programmers clearly find irresistible.
- JonChesterfield 3y agoAre you suggesting 3.times(2).plus(7) as a good thing or a bad thing? I see a.equals(b) occasionally from the first argument is magic crowd but 3.times is novel here. I'm really unsure what the order of operations is for that expression.
- gpderetta 3y agoC++ doesn't have extension methods, so you wouldn't be able to add custom algos to the set of chainable algos. Overloading operator| is a crude way to get the equivalent of extension methods without having to change the language.
- fsloth 3y agoThe majority of time in professional codebases is not spent on typing but reading and understanding code. "saves a bunch of time and makes code way more readable" Not when everybody defines their own operators. Note - we are discussing operator overloading, not operators as features in syntax. Operators at the syntax level make life a lot easier. But then everybody uses the exactly same operator semantics, not some weird per-project abstraction. The lines of code you wrote as an example are not saving anyones time, except when writing it if you are a slow typist and lack a proper IDE support for C++. If typing speed is an issue, get a better IDE, don't write terser code.
- jenadine 3y agoHiding the actual logic in extra boilerplate doesn't make it easier to read. The lines of code in the example save reader's time as they focus attention on the actual business logic. Yes, this assumes that operator overloading follows some convention, but you need to follow conventions regardless to make readable code.
- lost_tourist 3y agoby this reasoning should we get rid of templates/generics as well?
- enriquto 3y agoYES
- woooooo 3y agoMaking things explicit isn't necessarily boilerplate.
- joshuamorton 3y agoCode is read more often than written. Writing code that can be understood at a glance (by using common, well understood operators) optimizes for readability. I think your argument is basically "people should not aggressively violate the implicit bonds of interfaces", which is true. But that goes for all interfaces, not just and not in particular those around operators. We just have cases where it's common with operators because those are one of the few cases where we have lots of things that meet the interface and interact directly as opposed to hierarchically. The same kind of issue comes up with co/contravariant types and containers sometimes, but that's less often visible to end developers.
- throwaway894345 3y agoThe code isn't readable (you can't even reliably tell at a glance what the operator does) and it takes negligibly longer to write "add()" rather than "+" in your program (yes, 'add()' is more keystrokes and thus takes longer to type, but most of your program isn't addition instructions). I think what people should advocate is full DSL capabilities with some unambiguous gate syntax so people know precisely that `foo * bar` is not using the host language syntax. Overloading operators is ambiguous and vastly incomplete (everyone is holding up matrix math as the shining example for the utility of operator overloading and you can't even express dot product notation in C++!)--it's a hack at best.
- josefx 3y ago> The code isn't readable (you can't even reliably tell at a glance what the operator does) and it takes negligibly longer to write "add()" rather than "+" in your program (yes, 'add()' is more keystrokes and thus takes longer to type, but most of your program isn't addition instructions). Except now you replaced + with a name that tells you just as much/little as + does. So you made your program verbose for the sake of verbosity.
- throwaway894345 3y agoNo, you’ve made your program “verbose” (by a handful of characters) for the sake of clarity—there is no longer ambiguity about what code runs (of course, this assumes you aren’t similarly overloading named functions, which should also be disallowed).
- josefx 3y agoGiven that your example uses neither namespacing nor explicit typing you seem to preach do as I say, not as I do.
- throwaway894345 3y agoI don't know what example you're talking about. I haven't given an example in this thread. I think you may have me confused with another commenter.
- JohnFen 3y agoOperator overloading is like spicy peppers. A little bit can make the program better, but it's very easy to use too much.
- cogman10 3y agoUnfortunately, like spicy peppers, everyone's definition of "too much" is different. Some people are eating ghost chili peppers just fine while others are struggling with ketchup.
- Leo_Germond 3y agoWhich is why we've banned spicy food: it's just too risky to be used safely.