Re: [boost] Why does shared_ptr have a public reset() method

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-01-31 06:31:00

David Maisonave wrote:

> Why does boost::shared_ptr have a public reset() method?

Why shouldn't it? Can you explain the reasoning that lead you to this 
question?

> Why is this method not private?

It's not used internally, so there is no need to make it private. reset() is 
a simple shorthand for swapping your shared_ptr with a temporary 
default-constructed one, then destroying the temp. You can also achieve the 
same effect by assignment.

p = shared_ptr<T>(); // same as p.reset()

Don't tell me that your smart pointer doesn't support assignment. :-)

> In reading the introduction for weak_ptr, it seems like its main
> purpose is to cover up or control this opening to boost::shared_ptr.
>
> http://www.boost.org/libs/smart_ptr/weak_ptr.htm

This example is why weak_ptr doesn't have a get() member returning a raw 
pointer. reset() is used for simplicity, you can also pretend that p is 
simply destroyed instead of being reset.

> If boost::shared_ptr didn't have this type of public access, would
> there be a need for the weak_ptr?

Yes of course. The pointee can be destroyed without ever using reset.

> I can not find any example code that would justify the requirement
> for the weak_ptr other than the code in above link.

It's hard to explain the usefulness of weak_ptr with one simple example.

In short, weak_ptr allows you to keep an eye on a pointee without affecting 
its lifetime. You can periodically check whether the pointee is still alive 
and if so, obtain a shared_ptr to it (by using weak_ptr<>::lock). This 
shared_ptr would now temporarily keep the pointee alive until you are 
finished with it.

There is no single canonical use for weak_ptr. It's a versatile tool that 
can be used in every situation that matches the above description. Some 
people use for it to break shared_ptr cycles. Others use it instead of a raw 
pointer to check for dangling pointers. It can be used in a video game to 
store the current target of the unit or the current selection. It can be 
used in a document editor as a 'weak' reference to a portion of the 
document, if this portion can disappear. And so on.

The most often cited example is a cache. Imagine you having a collection of 
immutable objects that are expensive to create, such as images that are kept 
on disk. You receive a request from user code for image "test.tga" and give 
it a shared_ptr<image> to it. Now if you keep a weak_ptr, you'll be able to 
service the next request for "test.tga" without going to the disk if the 
first client is still using it.

I believe that this last scenario is one of the reasons for adding a weak 
reference to Java.