Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ah, so C++ pointers, even with "smart pointers" is still complicated and massively error prone.

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...




I might be biased, but I don't know that you can really call it massively error prone. Certainly, if you want to break the rules C++ will assume you have a good reason for it and let you shoot you in the foot all the way through the Earth's crust, but the smart pointer rules are actually fairly simple this time.

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 see your point of view, and I agree that in the right programmer's hands, it's fine. Unfortunately, as we've seen repeatedly, people over estimate their pointer abilities and it leads to all sorts of memory and security issues.

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


For almost all use cases, the issues mentioned don't even come up. You create a unique_ptr with std::make_unique, or a shared_ptr with std::make_shared. It lives its entire life as that type, and when you no longer need it, you forget about it.

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.


If programmers can't be diligent enough to learn simple unique pointers, they won't bother being diligent about any of their code.

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.


They're as "massively error-prone" as garbage-collected references in other languages.

> #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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: