I wonder why there's so little interest in fixing all the footguns in C++. I guess it doesn't matter much now since C++ is the new Fortran, but there are so many little things they could fix with a -std= flag.
* Reaching the end of a function the should return a value but doesn't should be an error by default.
* char is 8 bits
* they probably can't fix the broken bitwise operator precedence, but they can require brackets
* require braces for if & for bodies
* make vector::operator[] range checked by default (and add an unchecked version)
I guess by the time you get to the point of proposing changes to C++ you have Stockholm syndrome.
I guess they did add string::starts_with at least. After like 30 years.
I wonder why there's so little interest in fixing all the footguns in C++.
But there is a lot of interest. CppCon has multiple talks on how the language is too complex and/or what paths could be taken to simply it.
I guess it doesn't matter much now since C++ is the new Fortran,…
C++ isn’t the new Fortran, it’s the new C. Fortran had ultimate primacy in the numerical code domain, C++ is used there too but almost everywhere else too.
… but there are so many little things they could fix with a -std= flag.
The problem is that any change to behavior will break code. And in the cost benefit analysis, making the language more accessible to potential new users doesn’t, and shouldn’t, take priority over current users. Now, there is a balance to strike, but simplifying C++ basically must be done through adding new features and interfaces.
Reaching the end of a function the should return a value but doesn't should be an error by default.
There are some nuance around this, but in the general compiler warnings/attributes and static analysis can do catch the cases of interest. Even if the language was changed to require this, I doubt implementations could actually check all code paths in every function.
char is 8 bits
Recommend using fixed width integer types instead?
require braces for if & for bodies
This isn’t a problem I see beginners usually having. But this is a style of code I’ve seen in many high profile code bases and it would be a . Anyway, aclang-tidy check is enough to enforce this.
make vector::operator[] range checked by default (and add an unchecked version)
The checked version already exists as .at(). It’s regrettably not the default, but again, changing such behavior would be far too inconvenient for the billions of lines of code out there.
I guess by the time you get to the point of proposing changes to C++ you have Stockholm syndrome.
There is a lot of behavior that experienced C++ developers simply get used to, e.g. std::map[]. However the reason for the lack of proposals for fixing basic problems is that they’re DOE and/or equivalent to choosing an ant-hill to die on.
I guess they did add string::starts_with at least. After like 30 years.
Utility functions are nice but they are hardly the most pressing issues facing C++ users.
Sorry, no. There is no nuance around this. It should 100% be an error by default. Same with case fall through.
> Recommend using fixed width integer types instead?
Well yes, in a perfect world they would just remove non-fixed sizes from the language. But that's never going to happen. As an intermediate step they can at least specify the sized of types that are de facto fixed.
> Anyway, aclang-tidy check is enough to enforce this.
Sigh. Well it's good that I don't have to deal with this attitude in Rust at least!
Sorry, no. There is no nuance around this. It should 100% be an error by default.
It’s undefined behavior and there are justifiable reasons for being so. Requiring otherwise implies that implementations must exhaustively check every code path in a function. Such an analysis is extremely expensive, and even practically impossible for sufficiently complicated code, it also would need to work across translation units, e.g. akin to whole program optimization. Not to mention cases like linking against a binary library in which the compiler has nothing to analyze at all, or when a functionally impossible non-return path is found but the compiler can not prove to itself that it’s unreachable.
Ultimately there are situations in which non-void functions do not have a return value. Moreover, it is certain that a non-trivial amount of code is relying on such behavior. Therefore is unreasonable to make implementations non-conformant and it’s impossible to decide what a reasonable behavior should be otherwise, hence the behavior being undefined.
As an intermediate step they can at least specify the sized of types that are de facto fixed.
Why hurt non-standard platforms and encourage the use of poorly named integer types? Anyone who cares about this is already using fixed width types.
Sigh. Well it's good that I don't have to deal with this attitude in Rust at least!
Oh, and Rust doesn’t recommend using linting or code formatting tools like clippy or rustfmt?
By all means, use Rust if it’s an option for your needs. C++ is a very old language with all sorts of compromises.
* Reaching the end of a function the should return a value but doesn't should be an error by default.
* char is 8 bits
* they probably can't fix the broken bitwise operator precedence, but they can require brackets
* require braces for if & for bodies
* make vector::operator[] range checked by default (and add an unchecked version)
I guess by the time you get to the point of proposing changes to C++ you have Stockholm syndrome.
I guess they did add string::starts_with at least. After like 30 years.