CODEWITHSUNDEEP
c++smart-pointers
paul23
paul23

Reputation: 9455

smart pointers - why use them, and which to use?

general questions
Now I've been reading quite a bit about smart pointers, and shared pointers seem like "perfect" in many cases. However I also read about cyclical reference or something like that? Where shared_ptr can't be used? I'm having a difficult time undestanding this, can someone give a trivial example showing this?

Also I'm really wondering, what do weak_ptr's provide that normal pointers don't? - As they don't increase the reference count they give no guarantee that the memory they point at is still valid?

my personal project:
In a project I've 2 "global" containers (both containers are soon to be moved inside a class), both are filled with "objects". However both should "point" to the same object. An object can not exist outside those containers, and it should not be possible that one container does contain it, while the other doesn't.

Currently I simply use normal pointers for this, and have a createObject& destroyObject method to manage the memory.

Is this good design? Should I use smart pointers?

Upvotes: 3

Views: 560

Answers (4)

Matthieu M.
Matthieu M.

Reputation: 300299

For the specific issues of coordinating two different containers, one approach is to bundle the two containers within a class that will maintain this invariant.

Another is to use Boost.MultiIndex which already offers this guarantee. Takes a little bit of practice and I still recommend wrapping the access with relevant methods so that the user is offered a business-centric interface.

Upvotes: 0

obmarg
obmarg

Reputation: 9569

To answer your various questions:

Cyclical references are when 2 different objects each have a shared_ptr to the other object.

For example:

struct Foo {
     shared_ptr< Bar > m_bar;
};

struct Bar {
     shared_ptr< Foo > m_foo;
};


void createObject()
{
    shared_ptr< Foo > foo( new Foo );
    shared_ptr< Bar > bar( new Bar );
    foo->m_bar = bar;
    bar->m_foo = foo;
    //Neither of these objects will be released here
}

This can result in neither of the objects being free'd, as Foo will always keep the reference count to bar above 1, and foo won't be free'd because bar will always keep it's reference count above 1.

This is a situation that can be overcome with weak_ptr's as they do not increment the reference count. As you point out, this will not stop the ptr from being free'd, but does allow you to check that the object still exists before using it, which you could not do with a standard pointer.

As for the example you provided, you should almost always use smart pointers rather than raw pointers, as they allow objects to be free'd automatically when they go out of scope, rather than you having to ensure it is done yourself, which can be error prone. This is especially true in the case where you have exceptions, which could easily skip over any releasing code that you've written.

For example, this code could cause problems:

Foo* foo = createObject();
foo.doSomething();
deleteObject( foo );

If foo.doSomething was to except, then deleteObject would never be called and foo would not be free'd.

However, this would be safe:

shared_ptr< Foo > foo = createObject();
foo.doSomething();

The shared_ptr will automatically be released at the end of the code block, regardless of whether an exception has occurred.

There's a fairly good discussion of pointers and smart pointers here: Pointers, smart pointers or shared pointers?

Upvotes: 2

Fred Foo
Fred Foo

Reputation: 363817

Here's a trivial example of cyclic references:

struct Node {
    shared_ptr<Node> next;
};

int main()
{
    shared_ptr<Node> n1(new Node), n2(new Node);
    n1->next = n2;
    n2->next = n1;
}

n1 and n2 point to each other, so they form a cycle. Vanilla shared_ptr should only be used with directed acyclic graphs (DAGs). For cyclic ones, there's weak_ptr, which doesn't screw up the reference counting in the face of cycles, but should be used with care. Backpointers in a DAG or tree structure are a valid use case of weak_ptr, allowing you to back up in the structure.

Regarding your current project: yes, try shared_ptr, it might make your life a lot easier. You can check whether an object exists in both containers with use_count() >= 2; note the >=2 because you'll probably hand out pointers to the contained objects to client code, which increases the reference count.

Upvotes: 1

Chris Card
Chris Card

Reputation: 3266

If you use shared_ptr, you can end up with a circle of pointers, e.g. p1 -> p2 -> p3 -> p1, and then they will never get released. To break the circle you can use a weak_ptr, e.g. p1 sp-> p2 sp-> p3 wp-> p1, and then the shared pointers can be released automatically.

The point to remember is that even though smart pointers save you from remembering to delete resources explicitly, they are not a silver bullet, and you can still get memory "leaks", for example when you have a circle of pointers, and in a complex system they can be just as hard to track down.

Upvotes: 0

Related Questions