Hi -- I'm loving how easy shared_ptr makes object handling, but am not sure about how to use weak_ptr. Should I use it in places where previously I would have, say, returned a const reference? For example: struct MyClass { const OtherObject & other_object() const; }; Would become: struct MyClass { weak_ptr<const OtherObject> other_object() const; }; Or is this wasteful, having weak_ptrs construct from shared_ptrs every time I want to access an member object? Or have I missed the point completely? ;) One convention I thought I might adopt would be like this: struct MyClass { void set_other_object( shared_ptr<OtherObject> ); // setter weak_ptr<OtherObject> get_other_object(); // non-const getter const OtherObject & other_object() const; // const getter }; Of course, that could be all kinds of dumb for all kinds of reasons I don't know about. :) Cheers, Doug.
On 7/2/11 12:28 PM, doug livesey wrote:
Hi -- I'm loving how easy shared_ptr makes object handling, but am not sure about how to use weak_ptr. Should I use it in places where previously I would have, say, returned a const reference?
A weak pointer should be used where you need to keep a pointer around for an object, but you do not insist that the object stays around, but you do want to know if the object has gone away. The main use of this is circular references, where for example, object A has a pointer to B, and object B has a pointer to A. If both of these were regular shared_ptrs than once this combination was created, then it would never go away as both A and B have a strong reference to them. Making one of the links a weak pointer, says that when all other shared_ptr references to the pair go away, then both A and B go away. You do have to be a bit careful and think about the consequences, and if you change the pointer from B to A to be a weak-ptr, then if all shared_ptr references to A go away, but you still have some to B, then A will go away but not B, so B needs to be able to handle that case. -- Richard Damon
Hmm -- so I guess, in the cases I'm talking about, I should store a
shared_ptr, and just return a const refererence.
Then, if I need to have a copy of the member elsewhere to manipulate, I
could return a weak_ptr.
Thanks for that!
On 2 July 2011 18:06, Richard Damon
On 7/2/11 12:28 PM, doug livesey wrote:
Hi -- I'm loving how easy shared_ptr makes object handling, but am not sure about how to use weak_ptr. Should I use it in places where previously I would have, say, returned a const reference?
A weak pointer should be used where you need to keep a pointer around for an object, but you do not insist that the object stays around, but you do want to know if the object has gone away.
The main use of this is circular references, where for example, object A has a pointer to B, and object B has a pointer to A. If both of these were regular shared_ptrs than once this combination was created, then it would never go away as both A and B have a strong reference to them. Making one of the links a weak pointer, says that when all other shared_ptr references to the pair go away, then both A and B go away.
You do have to be a bit careful and think about the consequences, and if you change the pointer from B to A to be a weak-ptr, then if all shared_ptr references to A go away, but you still have some to B, then A will go away but not B, so B needs to be able to handle that case.
-- Richard Damon
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hmm -- so I guess, in the cases I'm talking about, I should store a shared_ptr, and just return a const refererence.
Note that it might be rather dangerous, if your caller would store such a const reference.
Then, if I need to have a copy of the member elsewhere to manipulate, I could return a weak_ptr.
Returning weak_ptr usually doesn't make sense (except for the case where you return it for tracking only). Note that shared_ptr is implicitly convertible to weak_ptr, so typically you return shared_ptr, and let the caller to decide what to do with it: if the caller indends to store it, but doesn't want strong referencing, it stores it as weak_ptr.
That further simplifies everything, thankyou! :)
On 2 July 2011 20:29, Igor R
Hmm -- so I guess, in the cases I'm talking about, I should store a shared_ptr, and just return a const refererence.
Note that it might be rather dangerous, if your caller would store such a const reference.
Then, if I need to have a copy of the member elsewhere to manipulate, I could return a weak_ptr.
Returning weak_ptr usually doesn't make sense (except for the case where you return it for tracking only). Note that shared_ptr is implicitly convertible to weak_ptr, so typically you return shared_ptr, and let the caller to decide what to do with it: if the caller indends to store it, but doesn't want strong referencing, it stores it as weak_ptr. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
doug livesey -
Igor R -
Richard Damon