Re: [Boost-users] [smart_ptr] Resetting an intrusive_ptr
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Scott Meyers Sent: Tuesday, May 02, 2006 1:00 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [smart_ptr] Resetting an intrusive_ptr
The reason for p = 0 working in intrusive_ptr's case is that intrusive_ptr has an assignment operator taking a raw pointer. The other smart
Peter Dimov wrote: pointer
types do not.
I understand that, my question was more about why this operation is supported only for intrusive_ptr.
[Nat] The library discourages casual conversion from Foo* to shared_ptr<Foo> because it is a Bad Thing when you instantiate a second shared_ptr<Foo> for the same Foo* value. Now you have two different reference counts floating around on the heap. When either goes to zero, every shared_ptr<Foo> value based on the other reference count becomes a land mine. On the other hand, intrusive_ptr is designed to be able to cope with casual conversion of exactly that type. That's why, unlike shared_ptr, the intrusive_ptr constructor that accepts a dumb pointer is not marked 'explicit'. Simple dumb-pointer assignment works for the same reason. Concerning the missing reset() method, I can only surmise that the author considered it unnecessary, given assignment support. I for one wouldn't object to it being added.
participants (1)
-
Nat Goodspeed