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@mac.com