I am by no means a C++ expert, a noob rather. It might be possible to make this generic, but it seems quite easy to forget a small detail here, and then be kneecapped because you forgot one of the overloads. So that in very few amount of edge cases your abstraction isn't actually cleaned up.
Better than nothing, and might be the most preferred way of doing things in C++, but it does seem dangerous to me. ;)
I used to program a lot in C++ but switched to a number of different programming languages since then. Everything in C++ is this way and it’s hard to understand that things don’t have to be this way when you’re in the trenches of C++.
I distinctly remember what a breath of fresh air it was to switch to Java and then later C# where in both languages an "int" is the only 32-bit signed integer type, instead of hundreds of redefinitions for each library like ZLIB_INT32 or whatever.
"Native" types like usize and isize as used in Rust I'm totally fine with.
What I got frustrated with in C/C++ is the insanity of each and every third-party library redefining every type. I understand the history and reasoning behind this, but it's one of those things that ought to have been fixed in the early 2000s, not decades later when it's too late.
I think by C++17 (14 even), it was in a very good state and since then, third party libraries are better and better. So really, a decade and a half later than you think it should have been.
C++ is a difficult language to use well but it becomes a lot easier when you turn on the 'correct' warnings. Turning on the `-Wdeprecated-copy-dtor` warning would help you not forget one of the cases in the rule of 3.
I would have loved it if this warning was on by default but sadly, you have to know to turn it on.
As far as I know, many experienced C++ programmers have a list of warnings they use for their projects and it varies by industry since different compilers will have different flags. When I was working on bigger C++ projects, one of the senior programmers would configure the warnings for everyone.
An easy start is to use `-Wall -Wextra -Wpedantic` for gcc and clang compilers. I would now add `-Wdeprecated-copy-dtor` to the list but I only learned about it writing this article.
It is possible, but it isn't hard to remember the rules. The scope of where you can mess up is isolated to the single class so it is generally possible to get this right. Manual memory management is easy when the new and delete are near each other, but you often need them far removed. RAII ensures the places you can mess up are close.
A static analisys tool can enforce the rule as well- you should have one.
unfortunately though this is one area that because c++ predates RAII it can't changethe defaults without breaking a lot of code. I am saying the problem is manageable - there is a real problem though. If you make a new language learn from this mistake.
RAII was something that C++ incidentally made possible. Nobody realized the power until after C++ existed. It was more of a "look at the cool thing we can do" when C++ was invented, only after did people realize just how great/powerful it is.
kind of both as I understand it. Destructors was something C++ was going for, but the full power doesn't seem to be something that was really understood for a long time after they existed. At least not in C++ as I remember it in those days. Maybe Bjarne has a better vision that my professors didn't share though.
They certainly didn't, because using destructors for RAII was already something I learnt in Turbo C++ 1.0 for MS-DOS manuals, back in 1993.
And by the time of Windows 3.x with OWL, Apple AppFramework, OS/2 CSet++, Motif++, they were used all over the place.
Easy to check those surviving manuals.
Also in 1995, the C++ lecture material at the university, back when everyone was implementing their own personal standard library, already discussed RAII design.
To note that even now there are plenty of universities that fail on their approach on how to teach C++, hence the Kate Gregory's talk aptly named "Stop teaching C" in the context of teaching C++.
Better than nothing, and might be the most preferred way of doing things in C++, but it does seem dangerous to me. ;)