Comment by uecker
6 months ago
I see it the other way round. People hurt themselves by using C++. C++ fans will never understand it, but it you can solve your problem in a much simpler way, this is far better.
6 months ago
I see it the other way round. People hurt themselves by using C++. C++ fans will never understand it, but it you can solve your problem in a much simpler way, this is far better.
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.
5 replies →
IMHO C++ scales far better for large, self-contained, personal projects though it requires slightly more initial investment.
And if you're targeting PC, you might be better off using Python to begin with (if perf is not a concern)
What specifically makes it scale better in your opinion?
- "All" C libraries use some form of namespacing (the typical mylib_dosomething kind of name); actual namespaces mean you don't write these prefixes over and over again when in the same namespace
- "Most" C projects do basic OOP, many C projects even do inheritance via composition and a fair few of these do virtual dispatch too
- Templates (esp. since C++20), lambda functions, overloads and more recently coroutines (which are fancy FSM in their impl), etc. reduce boilerplate a lot
- Containers (whether std:: or one's own) are far easier to work with in C++, a lot less boilerplate overall (GDB leveraged this during their migration iirc)
- string_view makes non-destructive substring manipulation a lot easier; chrono literals (in application code) make working with durations a lot more readable too
In the past decade or two, major projects like GCC and GDB have migrated from C to C++.
Obviously, C retains advantages over C++, but they are fairly limited: faster build times, not having to worry about exposing "extern C" interface in libraries, not having to worry about controversial features like exceptions and (contextually) magic statics and so on...
1 reply →