For example take the first mistake: "using a shared pointer where an unique pointer suffices". Unique pointers and shared pointers mean completely different things, if you know what they are, you would never think of mixing one for the other.
If I had to make an analogy, this is like "using a video with a single frame when an image suffices". The video may work, but that's not at all how you're supposed to use it, and surely, anyone who knows what a video and an image are would not make that mistake!
You'll notice that most of the remaining mistakes here are with the shared pointer and weak pointer. Thankfully, in the overwhelming majority of cases you don't need it at all, sticking to the very simple unique_ptr is what you want, and unique_ptr is practically FootProof™.
I figure the C++ smart pointers should be as easy to use as possible, without caveats vs. C style pointers or whatever.
Maybe that isn't practical in the C++ language design right now, but that's just how I see it.
cheers
The issues in the article had me banging my head, because they aren't how smart pointers are used in practice. The only time that you would call release(), for example, is when you are passing a pointer into a pre-C++11 API. Once you have done so, you wouldn't be worrying about calling delete anyways, because you have transferred ownership.
So you may design a better pointer for them (if possible) and still have a huge spaghetti ugly bug-ridden insecure unmaintainable codebase... But at least the pointers are easy!
Even of you make them program in a rubber room helmet language, they are going to cause just as many problems.
Tools like unique_ptr are meant to let the good programmers work more expressively and make fewer mistakes. They aren't meant to let random folks write perfect code without thinking and learning first.
> #1
Performance aside, unique_ptr gives you something that most languages don't have, unique ownership enforced at the language level. This makes code less error-prone. Disregarding #1 just gives you what you get everywhere else.
> #2
Basically just says, if your object isn't thread-safe, don't use it concurrently. Again, nothing specific to C++.
> #3, #4, #5, #6, #7
Well duh, don't use manual allocation or the deprecated auto_ptr in the first place.
> #8
That's the only real gotcha, and the reason why weak_ptr exists. It's the price for having RAII and destructors (because when the destructor is called, all your class members still have to be alive).
In return for keeping your pointer graph cycle-free, you get actual automatic resource management that isn't limited to memory.
I thought that's sort of what they were meant to fix. Apologies, haven't coded in C++ for several years (when auto_ptr still roamed the Earth). But it doesn't inspire confidence reading things like this that we've made much progress...