[Boost-users] ~intrusive_ptr bug?

From: Jean-François Brouillet (verec_at_[hidden])
Date: 2005-05-16 18:38:42

As observed in another thread, the intrusive_ptr destructor
in boost 1.32 does not honor its own status as defined in
the constructor with respect to the addRef boolean.

This snippet shows the problem:

     X * x = new X ;
     {
         intrusive_ptr<X> p(x, false) ;
     }

     // Here, x has been destroyed!

Is this a bug, or some requirement (that I couldn't find) that
if you ever pass "false" to the constructor, then that intrusive_ptr
is assumed to never go out of scope?

The fix would be simple:

     ...
     bool strong ;

     intrusive_ptr(T * p, bool add_ref = true): p_(p), strong(add_ref)
     {
         if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_);
     }
     ...
     ~intrusive_ptr()
     {
         if(p_ != 0 && strong) intrusive_ptr_release(p_);
     }

though it is less clear whether it would break some assumption I'm not
privy to.

Also, the above "fix" would increase the stack storage from the typical
4 bytes to probably 8 (due to alignment) just to store an additional  
bit.
Obviously, a less portable implementation could get away with storing  
the
bool as the low order bit of p_, masking it off when required ...

Should I go ahead an implement this fix with the knowledge that a future
revision of boost will include it, or is there any other  
consideration that
render this fix unlikely to make it into an official release ?

BTW: I did check the "unit tests" for intrusive_ptr at:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/ 
smart_ptr/test/intrusive_ptr_test.cpp

and this case is clearly not accounted for.
--
Jean-François Brouillet
verec_at_[hidden]