4 ms·
The fundamental issue pointed out in the post is an interesting one. It all begins with the assumption that with a language like C++, you can reason about thin
by zzalpha 11y ago
The fundamental issue pointed out in the post is an interesting one. It all begins with the assumption that with a language like C++, you can reason about things like performance without a lot of weird surprises.
Much of that reasoning begins with understanding the types involved.
Of course, I would argue if you wanted to complain about this, you should begin by rejecting operator overloading, which IMO is far more dangerous in this regard than the auto keyword. At least with auto, there's a visual indicator that something "magical" is going on, and if you want to really know the return type, you navigate to the function or whatever to figure out what that type is.
With operator overloads, code that looks totally innocuous can end up doing extremely surprising things.
- api 11y agoThere is another related dimension too: C++ is verbose for a reason and sometimes trying too hard to make a thing not what it is does harm. C++'s verbosity carries information that has value. Personally I tend to not even use typedef's as often as other programmers do. I do it for really verbose stuff at times but I prefer always seeing what a type actually is in most cases. I find that it actually makes code more readable, though it does make refactoring slightly more annoying.
- zzalpha 11y agoAgreed. It's absolutely true that in an object instantiation, declaring the type twice (in the variable declaration and again in the construction) is repetitive. And it's a flaw in all object-based algol-style programming languages, which is why the var keyword was introduced to C#, and the diamond operator (while a half-assed solution for only part of the problem) was added to Java. But that's just one narrow use case where I see this feature being worthwhile.
- Retra 11y agoOperator overloading would be fine if everybody had some standard for how to employ it sensibly. Unfortunately, the C++ standard library (over)uses it poorly all over the place, so it's really not setting an example of moderation.
- conistonwater 11y agoThis is a common sentiment I think, but operator overloading, at least in the context of numerical analysis, has perfectly sensible standards already, as in Matlab, R, python, julia, and the like, yet C++ under-uses it and doesn't even provide anything overloadable for matrix-multiplication (like `.* ` vs `* `) or a linear solve `\` operator. C is even worse, since you can't even define arithmetic operators for a custom numerical type.
- Retra 11y agoThat's true if you're only looking at arithmetical operators. C++ most often overloads assignment and indexing operators. You can even overload the cast operator, and if that isn't confusing and unnecessary... just don't ever use std::vector<bool>.
- vinkelhake 11y agoAside from vector<bool>, which pretty much everyone agrees is a failed experiment, where do you think operator overloading overused in the standard library?
- Retra 11y agoIterators using ++ Write/Read using << and >>. Not a major problem, but it's weird and not very useful when you're trying to be C compatible. You can index into a std::deque, but not a std::queue. I'd also count the need for explicit in constructor declarations to be a similar kind of mistake.