Boost logo

Boost Users :

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_);
         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
Obviously, a less portable implementation could get away with storing
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:*checkout*/boost/boost/libs/

and this case is clearly not accounted for.

Jean-François Brouillet

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at