Is there a rigid guideline as to when one should preferably use boost::shared_ptr over normal pointer(T*) and vice-versa?
+2
A:
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.
Evan Shaw
2009-08-11 14:47:19
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.
anon
2009-08-11 16:12:42
@NNeil, making pointer ownership explicit has nothing to do with design.
jon hanson
2009-08-11 16:16:48
@jon ownership, along with lifetime, is one of the two most important issues that any design must address and specify
anon
2009-08-11 19:41:11
@jon: In C++ world ownership is everything. Without it we may as well us C.
Martin York
2009-08-11 22:17:43
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
2009-08-11 22:25:45
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
2009-08-11 15:07:26
As long as nothing, you know, shares the pointer with the creating object.
John Calsbeek
2009-08-11 15:20:15
The non-standard copy semantics of auto_ptr can bite you hard if you aren't careful.
Fred Larson
2009-08-11 15:40:56
@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
2009-08-11 16:06:46
@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
2009-08-11 16:08:09
+1
A:
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
http://stackoverflow.com/questions/94227/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 http://stackoverflow.com/questions/1256803/using-abstract-class-as-a-template-type/1256923#1256923)
Martin York
2009-08-11 15:59:24