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