David Maisonave wrote:
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
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:<00f101c62659$d1264990$6507a8c0@pdimov2>... the
same effect by assignment.
p = shared_ptr<T>(); // same as p.reset()
Reading the weak_ptr introduction gave me a misunderstanding of what reset does. I thought reset just release the pointer without deleteing it if it was the last referenced. If it does delete it when it's the last reference, than it does make sense to have it public.
Don't tell me that your smart pointer doesn't support assignment. :-)
It not only supports assignment, but it also has the ability to assign to a different policy type.
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.
I just ran a test on this, and it seems that boost::shared_ptr does result in leaving memory leak in cycle logic. However, when I tested my proposed smart_ptr, it does not have this problem. It's able to correctly destroy the objects even in cycles. The proposed boost::policy_ptr also has the same cycle problem like boost::shared_ptr. I don't understand why they're not able to resolve this in the destructor call. Either I'm missing something in my smart_ptr, or there's some extra wacky logic in the boost::shared_ptr that's blocking deletion in cycles. (Which I don't get)