Question

I use shared_ptr in my application design, and I have tendency that more and more objects become heap-allocated instead of to be a simple objects on stack (or agregates of more complex objects).
Instead of simple (but with risk that Foo::bar will become dangling reference in more complex situation) …

struct Bar { };
struct Foo { Foo(Bar& bar) : bar(bar) { }; Bar& bar; };
int main() {
  Bar bar;
  Foo foo(bar);
  // ...
}

... I need to do ...

struct Bar { };
struct Foo { Foo(shared_ptr bar) : bar(bar) { }; shared_ptr<Bar> bar; };
int main() {
  shared_ptr<Bar> bar = make_shared<Bar>();
  Foo foo(bar);
  // ...
}

... because I want to avoid of manual objects life-time tracking
Did I missed point in shared_ptr usage or this is pay for automatic life-time management ? Or maybe this is bad design sign ?

Answer 1

It is a question of your object life cycle. You should use shared_ptr when you really share an object between multiple other objects.

In your case the owner of FOO and BAR must control the lifecycle of both. Maybe it is possible to make BAR a private member of you class FOO and let FOO control the life cycle.

I personally use the smart pointers to express the ownership of an object. Shared_ptr means that it is really shared and I am not the only owner of this object.
Scoped or unique pointer show that I am the only owner of the object. If you want to transfer the ownership you can use auto_ptr or the C++0x move semantics.

I have seen at least in bigger projects that the lack of life cycle control will lead to dangling objects. So you don’t have a direct memory leak any longer because of automatic life-time management but you get circular dependencies. Which lead to the same result.

To answer your question if this is bad design. It depends on what you are doing.