Hacker News Reader

Comment by tialaramex | Hacker News Reader

> std::unique_ptr ensures that no other std::unique_ptr will own its object

Literally all std::unique_ptr does is wrap the pointer. If we make two unique_ptrs which both think they own object X then not only will they both exist and point at X (so they don't actually ensure they're unique) they'll also both try to destroy X when they disenage e.g. at the end of a scope, leading to a double free or similar.

Uniqueness is a property you are promising, not one they're granting.

I expect you knew this, but it's worth underscoring that there is no magic here. This really is doing only the very simplest thing you could have imagined, it's a pointer but as an object, a "smart pointer" mostly in the same sense that if I add a cheap WiFi chip to this refrigerator and double the price now it's a "smart fridge".

View on HN

It's really asking for trouble if you view it that way - that you are going to allocate something, then uniquely pass it to a single unique_ptr, or shared_ptr, to manage and release. Better really to use std::make_unique() and std::make_shared().

The smartness, limited though it may be, is just that since it "knows" it's the owner, it knows that it's responsible for releasing it at the appropriate time (reference counted in the case of a shared pointer).

A lot of the value isn't just the automatic release, but that these classes, unique_ptr, and shared_ptr, are built to enforce their semantics, such as literally not being able to copy a unique_ptr, but are able to move it, and copying a shared_ptr being allowed and increasing the reference count of the object.

Yes - they are just simple classes, but using them as intended does avoid a lot of common programmer memory management mistakes, and highly adds to the readability of your program, and ability to reason about ownership, since use of these types rather than raw pointers in effect documents who the owner(s) are, and enforces that this documentation is the reality.

It's an important distinction, just like it's important to know that "const foo *" doesn't mean the foo is constant, just that YOU cannot change it.

Just because you build a unique_ptr from a raw pointer it doesn't mean that it is now magically owned by the object. You also have to ensure that no other place already did that, which unique_ptr simply cannot enforce.

Of course, you're right and my attempt to add precision was itself insufficiently precise. Hoisted by my own petard :(

Reply on news.ycombinator.com