Smart pointers: who owns the object? [closed]

Question

Simple C++ Model

In most modules I saw, by default, it was assumed that receiving pointers was not receiving ownership. In fact, functions/methods abandoning ownership of a pointer were both very rare and explicitly expressed that fact in their documentation.

This model assumes that the user is owner only of what he/she explicitly allocates. Everything else is automatically disposed of (at scope exit, or through RAII). This is a C-like model, extended by the fact most pointers are owned by objects that will deallocate them automatically or when needed (at said objects destruction, mostly), and that the life duration of objects are predictable (RAII is your friend, again).

In this model, raw pointers are freely circulating and mostly not dangerous (but if the developer is smart enough, he/she will use references instead whenever possible).

• raw pointers
• std::auto_ptr
• boost::scoped_ptr

Smart Pointed C++ Model

In a code full of smart pointers, the user can hope to ignore the lifetime of objects. The owner is never the user code: It is the smart pointer itself (RAII, again). The problem is that circular references mixed with reference counted smart pointers can be deadly, so you have to deal both with both shared pointers and weak pointers. So you have still ownership to consider (the weak pointer could well point to nothing, even if its advantage over raw pointer is that it can tell you so).

• boost::shared_ptr
• boost::weak_ptr

Conclusion

No matter the models I describe, unless exception, receiving a pointer is not receiving its ownership and it is still very important to know who owns who. Even for C++ code heavily using references and/or smart pointers.

For me, these 3 kinds cover most of my needs:

shared_ptr - reference-counted, deallocation when the counter reaches zero

weak_ptr - same as above, but it's a 'slave' for a shared_ptr, can't deallocate

auto_ptr - when the creation and deallocation happen inside the same function, or when the object has to be considered one-owner-only ever. When you assign one pointer to another, the second 'steals' the object from the first.

I have my own implementation for these, but they are also available in Boost.

I still pass objects by reference (const whenever possible), in this case the called method must assume the object is alive only during the time of call.

There's another kind of pointer that I use that I call hub_ptr. It's when you have an object that must be accessible from objects nested in it (usually as a virtual base class). This could be solved by passing a weak_ptr to them, but it doesn't have a shared_ptr to itself. As it knows these objects wouldn't live longer than him, it passes a hub_ptr to them (it's just a template wrapper to a regular pointer).

Don't have shared ownership. If you do, make sure it's only with code you don't control.

That solves 100% of the problems, since it forces you to understand how everything interacts.

• Shared Ownership
• boost::shared_ptr

When a resource is shared between multiple objects. The boost shared_ptr uses reference counting to make sure the resource is de-allocated when everybody is finsihed.

std::tr1::shared_ptr<Blah> is quite often your best bet.

From boost, there's also the pointer container library. These are a bit more efficient and easier to use than a standard container of smart pointers, if you'll only be using the objects in the context of their container.

On Windows, there are the COM pointers (IUnknown, IDispatch, and friends), and various smart pointers for handling them (e.g. the ATL's CComPtr and the smart pointers auto-generated by the "import" statement in Visual Studio based on the _com_ptr class).

• One Owner
• boost::scoped_ptr

When you need to allocate memory dynamically but want to be sure it gets deallocated on every exit point of the block.

I find this usefull as it can easily be reseated, and released without ever having to worry about a leak