this post was submitted on 17 Sep 2024
36 points (95.0% liked)
C++
1765 readers
1 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Adding a feature is one thing, C++ has added a lot of memory safety features over the years. The problem with C++ is it still allows a lot of unsafe ways of working with memory that previous projects used and people still use now. Removing support for these features will break existing code and piss a lot of people off in the process. It is not about adding new features, but removing the unsafe existing features that they are talking about here.
Why do you think this is a problem? We have a tool that gives everyone the freedom to manage resources the way it suits their own needs. It even went as far as explicitly supporting garbage collectors right up to C++23. Some frameworks adopted and enforced their own memory management systems, such as Qt.
Tell me, exactly why do you think this is a problem?
All the use after free and buffer overflow bugs that plague our key infrastructure.
It's not just that. Debugging segfaults and UB can be an absolute nightmare.
The C++ committee still haven't learnt their lesson. I recently learnt about C++20 coroutines, which are pretty neat, if complex (there are pretty much no good learning resources about them). However they are still putting unnecessary UB footguns in it.
Maybe a "pragma strict" where every deprecated is an error and not a warning?
Reminds me of how I found some safety measures to be in China some years back, basically those were signs saying "plz don't fall to your death, if you do it's your fault"
At least it's not like Russia, where it's “plz don’t fall to your death, if you do it’s our fault”...
I thought a lot of places are like that, that's why we get all the fences and such 🤔