[Boost-users] Re: ~intrusive_ptr bug?

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-19 18:46:50

Jean-François Brouillet <verec_at_[hidden]> writes:

>> So setting add_ref to false does not suggest that
>> intrusive_ptr_add_ref will not be called?
>
> Oh yes it does. What is does NOT suggest is that
> ~intrusive_ptr WILL call intrusive_ptr_release() MO MATTER WHAT
>
> That is this asymmetry which is cause of confusion, and for
> which I've still got a hard time figuring out a valid use case
> that would require this rather odd behavior.
>
> Let's assume we had intrusive_ptr2 with _exactly_ the same
> interface as intrusive_ptr but with the added behavior that
> if the constructor is called with "false", then the destructor
> does NOT call intrusive_ptr_release.
>
> What is the name you would choose for the "addRef" parameter?
> "managed" ? Or maybe, simply "addRef" after all, since you
> would _assume_ by virtue of the symmetric behaviour of a destructor
> w.r.t a constructor, that whatever the constructor does, the
> destructor un-does it, and whatever the constructor does NOT do,
> the destructor does NOT un-do.

Bad assumption with smart pointers.  Ctors don't allocate resources,
yet dtors deallocate them.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com