-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Brian Neal Sent: Monday, January 31, 2005 7:34 PM To: boost-users@lists.boost.org Subject: [Boost-users] Rationale for intrusive_ptr?

Hi, I need some help understanding when and why you would want to use intrusive_ptr. Does someone have an example? I didn't get much out of the current documentation for it. Thank you.

[Nat] Consider: class MyClass; void some_func(const boost::shared_ptr<MyClass>& ptr); class MyClass { public: void process() { // BAD THINGS HAPPEN! some_func(boost::shared_ptr<MyClass>(this)); } }; In our current project, we've been bitten more than once :-( by situations that are analogous but less obvious. Inside a member function, you don't have a shared_ptr<MyClass>, you only have a dumb MyClass* 'this' pointer. But if MyClass is managed with smart pointers, you probably have processing functions that accept only a smart pointer to MyClass. A natural-looking data conversion is easy to code and makes the compiler happy. What happens, though, is that when you instantiate a new shared_ptr<MyClass> from your dumb 'this' pointer, it gets a whole new refcount object! In the example above, the temporary shared_ptr<> goes away as you're about to exit MyClass::process() -- which makes its spurious refcount go to 0 -- which deletes the MyClass instance in question, even though there are probably still existing shared_ptr<MyClass> references to the same instance lying around! (e.g. the one with which you called the process() method) We now use intrusive_ptr almost exclusively (vs. shared_ptr). We limit its intrusiveness by deriving all subject classes from an intrusive_base we wrote, which contains the refcount we use and a couple of methods. This practice has cut down considerably on bizarre crashes.