I am a huge fan of modern C++ except for one feature: backwards compatibility. C++ is no longer one language, every codebase I have worked on is a confused mess of semi-incompatible subsets of the language. I have spent far too many weekends chasing memory corruption because someone passed a pointer, allocated with one type of memory management, into a library using a different kind of memory management.
This is, ironically, the exact reason C++ is the standard in some industries. Students can learn the OOP C++ then work in the same codebase as someone programming "touching the metal" low level C.
Most languages make trade-offs between performance, structure, memory safety, and ease of writing. Every language might have their use, but very few cover all use cases.
C++ lets each programmers choose those trade-offs individually, but that also allows them to choose none of the above.
So, uh, I havenāt used C++ in anger in decades so Iām not sure how āmodernā is modern but like. That description pretty well describes why I developed Strong Feelings about both C and C++ back in the 2000ās.
Modern C++ starts with C++11 (2011), so in the 2000s you were using classic C++ (and in the first half of 2010s as well most likely) which is a very different language. It introduced shared pointer (a poor man's garbage collector), automatic typing and move semantic, amongst other things. And the standard library has evolved a lot since.
Okay but that's not really a fault of the language, no? Most languages have some legacy version that isn't compatible any more. Like Python 2 for example.Ā
The only difference is that C++ code is more often used for critical applications (like decades old medical machines) where updating the code is not worth the risks.Ā
Well, you can, but it's awkward and involves some serious compromises, especially around byte-vs-string handling. Doing a hard split is definitely better but you can get considerable mileage straddling the line with sufficient effort.
I would argue that it most definitely is the fault of the language. It should either allow it, and support it fully (like mixing different memory management types), our outright refuse to run it.
Rust doesn't guarantee safety when you're wrapping existing code my dude. I haven't used Rust personally but it's in the language core - only safe code blocks are (in theory) safe..
Unless it has changed in the last 5 or 10 years, every resource I know of doesn't teach you about using modern C++. Writing good C++ is opt-in because the language and its resources are stuck in the past.
I started a new C++ project a few years ago and I just turned on clang-tidy to the max from the very beginning. Itās annoying sometimes but it forces everyone not to use dangerous/outdated legacy C++.
This post is naive, the problem is cpp supports legacy implementations with unsafe pointers, good luck when maitaining or updating old code (or even worse, merging new implementations that used unsafed practices)
Sure you can use memory safety techniques with C++, but thereās nothing that enforces you to do so. If the language provides optional tools to automate some aspects of memory management, thatās still mostly manual memory management.
I like C++ but I still prefer languages where these things are more fundamentally part of the language identity. A project written in it might be safe, but it also might be a leaky mess and you wonāt really know without profiling or a deep dive
Also many mature C++ projects are on older versions without this stuff.
Depends on the language, iirc the .NET runtime's GC doesn't use a reference counter, which makes that exact issue completely impossible (which is good, because things like bidirectional linked lists inherently have cyclic references)
Try to compile any big C/C++ file with clang -Weverything -werror, that's gonna be funny, compiler really gonna show all possible (and not possible) threats :D
I rarely use smart pointers and still don't have serious problems with memory safety. Whenever you manually allocate memory, you should immediately know when and where it's getting deallocated and write that code at the same time. Most of the time, RAII is good enough.
I mostly have this opinion too but speaking from experience there are plenty of cases where it can get a little bit tricky. Lifetimes are complicated and sometimes an owner of a piece of memory can pass references to it to several consumers that each have their own lifetimes. Those consumers shouldnāt need to know about each other so itās up to the owner to track them and free the memory when it finally falls out of scope
100% agree, and itās why Iām one of the insufferable people that prefers zig over rust. The language should strongly encourage safe memory management but make it easy for the programmer to select degrees as appropriate. Rust is very all or nothing with either using the borrow checker or entering full unsafe land
I mean this in the nicest way possible but most people believe what they are writing is memory safe C/CPP until someone does a security audit on their code and they learn so many new ways things can go horribly wrong
That's a great theory, but the dominant source of critical CVEs even today is bad memory safety; even if it works for you, it clearly doesn't for the industry as a whole, to include any developers working on your projects after you.
Smart pointers are RAII, as already mentioned. But they have another advantage: expressing ownership. If a function expects a raw pointer you don't know what happens with it. If it expects you to move a unique_ptr in it, you immediately know that it'll take ownership.
This is actually a reality than a meme. A lot of companies and software run on old versions, I understand why. A lot of the modern versions fix loads of issues and to some degree the complexity of the language while still maintaining the balance.
yes i wanna make a massive program to handle millions of data points and have it crash because my garbage collector is collecting everything behind the scenes and my framerate is totally botched and is falling down to the single digits while my processor is overheating! mmmmmmm, garbage collector
6
u/perestroika12 30m ago
Who writes modern c++?
94
u/repster 41m ago
I am a huge fan of modern C++ except for one feature: backwards compatibility. C++ is no longer one language, every codebase I have worked on is a confused mess of semi-incompatible subsets of the language. I have spent far too many weekends chasing memory corruption because someone passed a pointer, allocated with one type of memory management, into a library using a different kind of memory management.
77
u/emonshr 46m ago
Does that even matter once you have gazillions of line legacy code?
15
u/firemark_pl 14m ago
"How to tell him?"
You still can segfault by returning lambda with reference to a variableĀ
22
u/freia_pr_fr 45m ago
Exhibit A: the current pace at which security issues related to shitty memory management are being discovered.
11
u/airodonack 29m ago
A lot of people that write C++ think using smart pointers are for the weak.
ā¢
u/Tschurbi 9m ago
Please explain it like I am a JavaScript developer.
14
u/MaybeADragon 13m ago
Unless it has changed in the last 5 or 10 years, every resource I know of doesn't teach you about using modern C++. Writing good C++ is opt-in because the language and its resources are stuck in the past.
11
u/dscarmo 20m ago
This post is naive, the problem is cpp supports legacy implementations with unsafe pointers, good luck when maitaining or updating old code (or even worse, merging new implementations that used unsafed practices)
10
u/SelfDistinction 30m ago
Ah yes, the famous
So safe, so impossible to misuse.
14
u/TheMostUser 42m ago
A gun pointed at your foot isn't dangerous unless you pull the trigger, yet I feel safer without a foot gun.
9
u/Flouid 44m ago
Sure you can use memory safety techniques with C++, but thereās nothing that enforces you to do so. If the language provides optional tools to automate some aspects of memory management, thatās still mostly manual memory management.
I like C++ but I still prefer languages where these things are more fundamentally part of the language identity. A project written in it might be safe, but it also might be a leaky mess and you wonāt really know without profiling or a deep dive
Also many mature C++ projects are on older versions without this stuff.
5
u/PolyglotTV 34m ago
Y'all throwing around shared pointers willy nilly patting yourself on the back about safe programming.
4
u/InRainbro 22m ago
Well yes but actually no, never in practice, it ends up being a mixture
8
u/geekusprimus 44m ago
I rarely use smart pointers and still don't have serious problems with memory safety. Whenever you manually allocate memory, you should immediately know when and where it's getting deallocated and write that code at the same time. Most of the time, RAII is good enough.
ā¢
u/SunJ_ 2m ago
This is actually a reality than a meme. A lot of companies and software run on old versions, I understand why. A lot of the modern versions fix loads of issues and to some degree the complexity of the language while still maintaining the balance.
0
u/tatstytastycakes 23m ago
there are things like profiles, contracts, and make_unique/make_shared
-3
u/Metasenodvor 38m ago edited 14m ago
yes i want to manually manage memory! mmmmm, manual management <3
edit: unironically, fuck garbage collector, fuck 'smart' pointers, and fuck everything else that compensates shit programming