Usage guidelines: shared versus normal pointers

Question

Is there a rigid guideline as to when one should preferably use boost::shared_ptr over normal pointer(T*) and vice-versa?

Are you referring to `boost::shared_ptr` and `std::tr1::shared_ptr`? — bdonlan, Aug 11 '09 at 14:40
You should practically never use a RAW pointer. But their are multiple shared pointers for different situations. See http://stackoverflow.com/questions/94227/smart-pointers-or-who-owns-you-baby — Martin York, Aug 11 '09 at 15:55

score 2 · Accepted Answer · answered Aug 11 '09 at 14:47

2

My general rule is, when memory gets passed around a lot and it's difficult to say what owns that memory, shared pointers should be used. (Note that this may also indicate a poor design, so think about things before you just go to shared pointers.) If you're using shared pointers in one place, you should try to use them everywhere. If you don't you'll have to be very careful about how you pass around pointers to avoid double frees.

If your usage of memory is simple and it's obvious what owns memory, then just use normal pointers.

Typically the bigger your project is, the more benefit you'll get out of shared pointers. There aren't rigid rules about this and there shouldn't be. As with many development decisions, there are trade offs and you have to do what's best for you.

answered Aug 11 '09 at 14:47

Evan Shaw

23,839
7
70
61

1

My rule is that if it is difficult say "what owns that memory", you have a poor design. Applying a shared pointer band aid isn't going to fix it. – Aug 11 '09 at 16:12
@NNeil, making pointer ownership explicit has nothing to do with design. – jon hanson Aug 11 '09 at 16:16
@jon ownership, along with lifetime, is one of the two most important issues that any design must address and specify – Aug 11 '09 at 19:41
@jon: In C++ world ownership is everything. Without it we may as well us C. – Martin York Aug 11 '09 at 22:17
Even in a good design, shared pointers go a long way towards making memory leaks and double-free bugs less likely. The programmer no longer has to worry about making sure every code path frees the data exactly once; now the compiler does that job for him. – Jeremy Friesner Aug 11 '09 at 22:25

score 2 · Answer 2 · answered Aug 11 '09 at 14:49

2

A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new.

— boost::shared_ptr documentation

answered Aug 11 '09 at 14:49

John Calsbeek

35,947
7
94
101

1

if you're only worried about memory leaks with new you can use `auto_ptr` and not have the overhead of a `shared_ptr`. – Matt Price Aug 11 '09 at 15:07
As long as nothing, you know, shares the pointer with the creating object. – John Calsbeek Aug 11 '09 at 15:20
The non-standard copy semantics of auto_ptr can bite you hard if you aren't careful. – Fred Larson Aug 11 '09 at 15:40
1

@Matt: The compiler does a good job of optimizing a shared_ptr the overhead is minimal. Use auto_ptr what it is designed for (ownership movement). Within a single scope scoped_ptr is better choice. – Martin York Aug 11 '09 at 16:06
@Fred: If you understand what auto_ptr is for it is the most useful smart pointer out there. Like all softeare don't abuse it and it will not bite you. – Martin York Aug 11 '09 at 16:08

score 1 · Answer 3 · edited May 23 '17 at 12:01

Unless you are building a smart pointer (don't) then you should probably not be using a RAW pointer (That way leads to madness).

There are a set of smart pointers for different situations:
std::auto_ptr:
std::tr1::shared_ptr AKA (boost::shared_ptr)
boost::scoped_ptr
boost::weak_ptr

Smart Pointers: Or who owns you baby?

The only reason for passing a pointer is to pass a reference to an object that could potentially be NULL (otherwise use a reference) ie you are NOT passing ownership just the use of the object (and if you are passing NULL maybe you should look at the code and ask why).

The std containers don't handle references well so you can put pointers to objects owned by somebody else in a standard container (see Using abstract class as a template type)

Usage guidelines: shared versus normal pointers

3 Answers3