Boost logo

Boost :

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

> 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.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at