I'm falling out with shared_ptr

Today's insight is short. Don't go crazy with the shared_ptr template. It's got its uses but don't overuse it. I did it. I'm paying for it. My code looks horrible and I get extra work overhead cleaning it up. The lesson is simple:

Only use shared_ptr when responsibility for the allocated object is shared.

How do you think it got its name? Whenever you can distinguish one single entity that is responsible for creation and destruction you don't need a shared_ptr. So what's the problem? Well, for one it's horrible to write so you'll end up with hundreds of typedefs to keep it down. An extreme example (very common in my code though):

std::map< std::string, std::tr1::shared_ptr< SomeClass >> stringToClassMap;

So easy to avoid since I almost always create and destroy the objects in ctor/dtor pair anyway.

Further, shared_ptr ruins my spartan include structure. Imagine this is in a header:

class SomeClass;SomeClass *someObject;

This does not require any extra includes. The forward declaration of SomeClass is enough. However:

std::tr1::shared_ptr someObject;

This requires that the full declaration of SomeClass is included because the compiler needs it to specialize the template. The result is longer compile times since my headers gets bloated with extra inclusions.

This may have come out as me running a hate campaign against shared_ptr. I don't, but seeing my own mistakes I try to preach modesty in its use. It's still very useful when passing heap objects around that don't have a distinct owner/manager and needs to be reference counted. Just trust in your ability as a programmer to free what you allocate and you won't need it most of the time.