Comment by pjmlp
6 months ago
We won't, because C++ is Typescript for C.
It offers us safety features for arrays and strings, that apparently WG14 will never add to C.
Didn't so in 40 years, and still remains to be seen what will be done with the current trend of cybersecurity laws.
Then there is the whole basic stuff like proper namespaces instead of the ridiculous prefix convention.
This from a point of view of C++ ARM defacto standard back in the 1990's, not even considering anything else.
I see more possibilities for people to hurt themselves using C than C++, since 1993 when I added C++ to my toolbox.
The stl is also unsafe by default and not actually safer than what you can also do in C.
I debugged enough problematic C++ code to know that people can hurt themselves badly with it.
Contrary to C standard library, all C++ compilers have provided safe versions of their standard libraries, predating C++98, enabled in debug mode.
Even if non standard, all major C++ compiler vendors have provided similar features on their standard library, and is now officially supported in C++26.
I have debugged enough C memory corruption issues with strings and arrays, that I would thought by now WG14 would actually care to fix the root cause, 40 years in.
The C standard library does not have containers, so I do not see how this sentence makes any sense. The reality is that C++ STL is in practice not really safer than C arrays, and although you can activate bounds checking, there remain many gotchas. But I am happy to see that bounds checking is now becoming official with C++26. For C arrays you get bounds checking in practice with -fsanitize=bounds. For containers, you would need a library in C that does bounds checking. So in both languages it is possible to get bounds checking if you want to.
4 replies →