Question

Just wanted opinions on a design question. If you have a C++ class than owns other objects, would you use smart pointers to achieve this?

class Example { public:    // ...  private:   boost::scoped_ptr<Owned> data; }; 

The ‘Owned’ object can’t be stored by value because it may change through the lifetime of the object.

My view of it is that on the one side, you make it clear that the object is owned and ensure its deletion, but on the flipside, you could easily just have a regular pointer and delete it in the destructor. Is this overkill?

Follow up: Just wanted to say thanks for all your answers. Thanks for the heads-up about auto_ptr leaving the other object with a NULL pointer when the whole object is copied, I have used auto_ptr extensively but had not thought of that yet. I make basically all my classes boost::noncopyable unless I have a good reason, so there’s nothing to worry about there. And thanks also for the information on memory leaks in exceptions, that’s good to know too. I try not to write things which could cause exceptions in the constructor anyway – there are better ways of doing that – so that shouldn’t be a problem.

I just had another question though. What I wanted when I asked this question was to know whether anyone actually did this, and you all seem to mention that it’s a good idea theoretically, but no one’s said they actually do it. Which surprises me! Certainly one object owning a pointer to another is not a new idea, I would have expected you all would have done it before at some point. What’s going on?

Answer 1

It’s a good idea. It helps simplify your code, and ensure that when you do change the Owned object during the lifetime of the object, the previous one gets destroyed properly.

You have to remember that scoped_ptr is noncopyable, though, which makes your class noncopyable by default until/unless you add your own copy constructor, etc. (Of course, using the default copy constructor in the case of raw pointers would be a no-no too!)

If your class has more than one pointer field, then use of scoped_ptr actually improves exception safety in one case:

class C {   Owned * o1;   Owned * o2;  public:   C() : o1(new Owned), o2(new Owned) {}   ~C() { delete o1; delete o2;} }; 

Now, imagine that during construction of a C the second ‘new Owned’ throws an exception (out-of-memory, for example). o1 will be leaked, because C::~C() (the destructor) won’t get called, because the object has not been completely constructed yet. The destructor of any completely constructed member field does get called though. So, using a scoped_ptr instead of a plain pointer will allow o1 to be properly destroyed.