[quote name='mrbastard' timestamp='1343129554' post='4962566']
Worth noting that one of the potential performance issues with shared_ptr is that the ref count has to be allocated on the heap.

Boost also provides intrusive_ptr - same as shared_ptr but the ref count is a static member of the pointed-to class. If you care, and don't mind changing your pointed-to classes, that is.

Not necessarily true for modern shared_ptr implementations. If you use make_shared to allocate your object the ref count will be merged with the object allocation. It also does some optimizations to reduce the memory usage of shared_ptr.
[/quote]
There is one caveat with boost::make_shared worth mentioning: in general, no memory can be freed until the last weak_ptr referencing the object has been released. This is usually completely irrelevant unless you weak reference a lot of small objects or some really big ones. As said, it does not matter for normal use cases but in extremely special applications you might be better off with separate allocations.

Edit: rip-off added something I only implied instead of saying it outright. Since it is an important but subtle difference, I'm saying it once more using a different choice of words: if you use boost::make_shared to allocate an object of type T, the instance is destroyed (using its destructor) when the last shared_ptr holding it is reset. But the memory occupied (sizeof(T) + sizeof(what shared_ptr needs)) is not freed until the last weak_ptr holding that instance is reset.