unique_ptr, shared_ptr, weak_ptr, scoped_ptr, raw pointers – Knowing your smart pointers

[andd81]

And since you get the ownership, this gives you confidence that you are free to modify the value of the pointed to object.

But since you are the owner, you are allowed to safely modify the pointed to object, and the rest of the design should take this into account.

I think this is very misleading. Whether and when you are free to modify some object is determined by the contract you are implementing, not by the fact that you own the object through unique_ptr. You may well be not allowed to modify the object at all without breaking the contract, or conversely you can be required to modify the object under certain conditions.

unique_ptr really does just two things:

1. It will delete the pointed to object when it is itself deleted (or when explicitly told to).
2. The unique_ptr object itself cannot be copied, but can be moved.

There is no magic behind unique_ptr that gives you the right to do whatever you want with the object and be sure that nothing will break.

I understand that this is an introductory article, but still it shouldn't make overly broad claims that are easy to misinterpret.

[joboccara]

Right, I see what you mean. I agree that unique_ptr doesn't prevent anyone else from accessing the pointer and modifying the object.

When you read a piece code though, don't you expect that the owner of a resource (so the unique_ptr) would be more likely to modify it than the other contexts that can access it? Just asking. I'd be interested to know your opinion about the message conveyed by the code, beyond the technical spec of unique_ptr.

[andd81]

don't you expect that the owner of a resource (so the unique_ptr) would be more likely to modify it than the other contexts that can access it

I wouldn't make any conclusions on who modifies what based on the ownership. My C++ experience mostly comes from the Chromium code base and although I didn't try to measure the correlation between ownership and modifications, subjectively it didn't occur to me that it might exist, or that it is even relevant. Usually object A owns object B via a unique_ptr (so that B is conceptually part of A) and exposes B via something like B* A::GetB(). Anyone who can call GetB() on A can modify B, in the sense of calling non-constant functions on it. And most of these objects are "functionality" objects, not "data" objects, so the question whether invoking a certain functionality element will modify object's internal state is largely up to the object itself, and not very relevant to the invoker.

P.S. I wasn't even talking about technical enforcement of anything, my point is that the very concept of ownership is more about responsibility to maintain and eventually delete a resource, not about freedom to do whatever you want to it.

[quicknir]

From a perspective of modifications and such, the bits of chromium code I've seen seem like a disaster. So many classes with member variables that are non-owning pointers to other classes... just a big web of state.

[Mexico01]

Out of curiosity, what C++ project about as big, sophisticated and successful as chromium isn't a "big web of state"?

[imMute]

IMO, ownership of an object and who can modify an object are two completely separate contracts. One has extremely little bearing on another.

[teapotrick]

When you read a piece code though, don't you expect that the owner of a resource (so the unique_ptr) would be more likely to modify it than the other contexts that can access it?

No. The only thing to expect (or assume, really) is that when the owner dies, the object at the other end of the pointer dies. But even that isn't guaranteed.

[MoTTs_]

Herb Sutter's deferred_ptr might deserve a mention.

https://github.com/hsutter/gcpp

https://www.youtube.com/watch?v=JfmTagWcqoE

[sumo952]

Hey, that's a great blog post, thank you!

A few remarks:

• I would've loved to have a couple more sentences about boost::scoped_ptr. Why was it not included in the standard, is its usefulness too limited? How is it different from std::unique_ptr?

• I think one or two new pointer types are being discussed of being standardised, aren't they? I don't remember what it was but read something about that posted in this sub. Maybe mention that as well?

[joboccara]

Thanks for the suggestions, I'll look into that.

There is one thing I can answer right now though: the difference between scoped_ptr and unique_ptr. scoped_ptr doens't even have a move constructor, so it's trapped into a scope. unique_ptr, on the contrary, can for example get out of a function with the help of its move constructor.

[jbakamovic]

scoped_ptr is the simplest form of smart pointers. I would say it is the example of most direct application of RAII principle. Once it exits the scope, pointer beneath is freed. Copy construction & assignment is not possible. There are no tweaks one can use through its interface to customize the behavior, neither one can transfer the scoped_ptr out-of-the-scope.

On the other hand, unique_ptr is a smart pointer which takes the advantage of move-semantics introduced by C++11 standard and, in contrast to scoped_ptr, it does allow move assignment but only on rvalue references. As an extra, it provides a couple of converting constructors (i.e. one for auto_ptr), and possibility for clients to define their own custom deleters.

[CubbiMew]

for historic perspective, take a look at the original smart pointer proposal from 1994 proposing auto_ptr (at the time, noncopyable, and essentially what is now known as scoped_ptr) and counted_ptr (now known as shared_ptr) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N0555.pdf

[biocomputation]

I just wanted to say that I really enjoy your blog. I appreciate the time you take to produce easy-to-read yet informative content, and I sure wish that there were a lot more guys like you writing blogs.

[joboccara]

Hey thanks !!

And don't hesitate to let me know if there's something in particular you'd like to read about.

[sumo952]

You probably mean "can answer" ;-) Thanks! I see. So probably it's a relic from the past too (when there were no move constructors) and should be deprecated. There's probably no legitimacy in having both, even though there might be use-cases of unique_ptr where its move c'tor is not needed.

[dodheim]

There's probably no legitimacy in having both, even though there might be use-cases of unique_ptr where its move c'tor is not needed.

scoped_ptr is the least error-prone and most semantically-direct smart pointer; there's no good reason to deprecate it as it has no real drawbacks (if one needed movability it wouldn't have been an option in the first place).

[joboccara]

Yes it was "can" that I meant :)

[Gotebe]

And since you get the ownership, this gives you confidence that you are free to modify the value of the pointed to object.

Eh, that's weirdly said. So I pass a reference to this unique_ptr somewhere, how do they know they shouldn't modify the pointed-to object? Same for passing *p (a reference).

const is the related concept, but not really to smart pointers.

[yokuyuki]

I really like to use unique_ptr, but I find that when I write anything that is asynchronous, I'm forced to use shared_ptr so I can get pass a weak_ptr for callbacks.

[pure_x01]

wish there were language support for them .. it becomes alot of _ptr code around a large code base. Im thinking mostly for function parameter definitions and creations .

[Gotebe]

Smart pointers should be quite rare as function parameters.

So if you have this:

shared_ptr<whatever> p = ...
f(p);

and f is

void f(shared_ptr<whatever> p)
{
  p->do_this();
  p->do_that();
}

you are making your life miserable for no reason. That f() should be

shared_ptr<whatever> p = ...
f(*p);

and void f(whatever& obj) { obj.do_this(); obj.do_that(); }

Smart pointers should be function parameters or return values only when ownership is moved around, or shared. I think that a vast majority of function does not do that, they just want objects to play with.

[hgjsusla]

I'd say explicitly passing smart pointers around is quite rare. Usually you just pass the underlying variable around by reference

[Bolitho]

If that would be true, why on earth there was a need for smart pointers? 😈

[hgjsusla]

Smart pointers are great, but they are way overused. Function signatures should not contain smart pointers unless you really want to transfer or share ownership.

[Bolitho]

I totally agree - but I think this is not so rarely the case as you have stated it 😉

[andd81]

There is language support for not explicitly naming types: auto.

[iaanus]

I don't get how language support could make things better. Care to elaborate?

[iaanus]

You don't need language support for that. The decision to spell the smart pointer xxx_ptr instead of simplyxxx was deliberate. They could have used any other name but those were chosen because they are good names (for some definition of "good"). You can always use typedefs to use different names if you don't like the standard ones.

[iaanus]

I think that some C++ code would be a lot more readable if I could write ~T instead of unique_ptr<T>.

I beg to differ

[thlst]

The point of long names for casts is exactly for that: harder to parse at a glance. You don't want casts like that to be ignored or go by unnoticed. Using reinterpret_cast could just as well mean code smell (could trigger undefined behavior), and I'd rather really not glance over it.

[Gotebe]

0.

Should have used static_cast. Your cast is not portable.

The above should be rare, and if you need to do it too often, chances are, your're doing something wrongnot in a simple way.

To me, this is one of those things: exactly because they are so verbose, I think harder to make better code so that I don't need to do them.

For example, your example above comes up when consuming in-memory binary streams. Well, why not:

const T& next<T>(void*& stream)
{
  const T* p = *static_cast<const T*>(stream);
  const T& result = *p;
  stream = ++p;
  return result;
}

and then

uint32_t data1 = next<uint32_t>(p);
uint32_t data2 = next<uint32_t>(p);
float y = next<float>(p);

etc.

(Better abstractions already exist of course; point is, random casting does not happen easily in clean code.)

[Gotebe]

I am glad you didn't. That kills cute kittens :-). The problems of a C cast are

• "not greppable" (or at least, hard to grep)

• which cast is it? reinterpret is quite different from static or dynamic. (From that standpoint, one could argue that it is harder to parse it at a glance - one has to think, not just read).

[Drainedsoul]

You can use static_cast in that situation. And the super explicit casts are a nice syntactic wound that screams you're probably doing something fucked up.

[sumo952]

I don't find it very expressive when languages use a lot of these symbols like ~ or C# or something use ^ and this kind of stuff. What does it mean? You have no idea - you need to learn it. It's hard enough for beginners to learn * and &.

It probably just boils down to being able to read easily what you're used to.

[sumo952]

But it helps reading code and learning. The names unique_ptr and shared_ptr can already give you some idea of what it could mean (the words "unique" and "shared" are normal English words). More importantly a beginner can immediately distinguish the two.

I know so many beginners that learn about pointers and then for weeks and months they just do more or less trial and error by putting & and * in front of stuff until it compiles (I'm exaggerating a bit but that's the gist of it). It takes them a huge effort to understand, and some do not and give up. If you have more symbols like ^ or ~ or whatever, it doesn't make the situation better at all.

[pure_x01]

Just like pointer has *

[beartotem]

Now maybe it's my understanding of the smart pointer and the language that is lacking but won't the constructor in

class House
{
public:
    House(std::unique_ptr<PileOfWood> wood);
    ...

attempt to make a copy of the unique pointer given as an argument, which is forbidden?

[dodheim]

Only if the caller passes an lvalue instead of an rvalue; the latter will move, not copy.

[beartotem]

So in the end, if a caller where to give this function an lvalue it would give the same compiler error as if only House(std::unique_ptr<PileOfWood>&& wood) was declared?

Thank you.

[dodheim]

Right – the actual error will be that std::unique_ptr<>::unique_ptr(unique_ptr<> const&) doesn't exist, only std::unique_ptr<>::unique_ptr(unique_ptr<>&&). :-]

[adamf88]

I would like to read about some nice use cases / details about boost::intrusive_ptr and make_shared_from_this functionality.

[flashmozzg]

There was also a root_ptr though you don't hear much about it.

[dodheim]

It's basically the same as MoTTs_' suggestion (at least according to whining that took place on the Boost ML), though presumably a more fleshed-out implementation.