Here's the class we use in production: /** Helper template mixin for @c boost::intrusive_ptr. To add support for intrusive pointer to class @c T, it should inherit from @c reference_counter<T>. This will - provide a reference count member - force the reference count to initialize to zero - define the add and release global functions required by @c intrusive_ptr If this class is not inherited publically, then the class @c T must declare the global functions as friends to permit them to cast @c T* to @c reference_counter<T>*. This can be done with the following two lines, with either the @c self typedef or the string "self" replaced by the actual name of class @c T. @code friend void boost::intrusive_ptr_add_ref(self*); friend void boost::intrusive_ptr_release(self*); @endcode @note Due to changes in the C++ standard and design decisions in gcc, it is no longer possible to declare a template parameter as a friend class. (Basically, you can't use a typedef in a friend declaration and gcc treats template parameters as typedefs). @note You can use this with insulated (by name only) classes. The important thing is to make sure that any class that uses an @c intrusive_ptr to a by name only class has all of its constructors and destructors declared in the header and defined in the implementation translation unit. If the compiler generates any of those, it will not compile due to missing functions or methods. */ template <typename T> class reference_counter { protected: typedef reference_counter self; //!< Useful for self type reference //! Default constructor. reference_counter() : m_reference_count(0) { } /** Copy constructor. @note Always initialize to zero. Ignore the source count. This makes it nicer for clients who can now use the default copy constructor. */ reference_counter(self const&) : m_reference_count(0) { } /** Assignment operator. @note Prevent the count from being assigned. */ self& operator= (self const&) { return *this; } int m_reference_count; //!< The reference count //! Define the helper functions and give them access //!@{ friend inline void intrusive_ptr_add_ref(T* t) { ++(static_cast(t)->m_reference_count); } friend inline void intrusive_ptr_release(T* t) { if (--(static_cast(t)->m_reference_count) <= 0) delete t; } //!@} };

At 04:57 PM 7/30/2008, you wrote:

Compared to mine, better sides: Worse sides: 1. No thread safety (may be you do not need it, but i need). 2. No const awareness, i think the following will fail: boost::intrusive_ptr<const test> p(new test); boost::intrusive_ptr<const test> q(new test); p = q; 3.m_reference_count is visible to derived classes.

1) Yes, but as you note it's trivial to add if it's important. I had that in my own implementation of intrusive_ptr (before those were in Boost) but dropped it because I never used it. Not such a big deal on Win32, but I remember it being painful on Sun / Sparc systems (am I dating myself?). 2) Interesting. I have been using this code for years and not had that come up. I'll have to take a look. 3) A design feature for me. It makes copy on write semantics easier to implement. You might consider putting in "bool is_shared() const { return m_reference_counter > 1; }" for that case.

At 08:26 AM 7/31/2008, you wrote:

I would rather put "bool is_shared() const { return m_reference_counter > 1; }" as protected member, and m_reference_counter as private one. Do you need it for something like "intrusive_from_this()" form Boost.Statechart ?

I haven't used Boost.Statechart so I can't speak to that. I do lot of psuedo-value classes, which are PIMPL classes based on intrusive_ptr that do copy on write to act like values instead of handles when it matters (Qt from Trolltech does a lot of that, for a public example). That has an obvious need to test for the reference count being larger than 1. Rather than is_shared(), you might duplicate the shared_ptr interface, with unique() and use_count(). That'd probably be better for something including in Boost.

Alexander Gutenev writes:

Updated, after looking into other's implementation:

I would add IncrementPolicy with following default. struct trivial_increment_policy { void inc( long& c ) { ++c; } bool dec( long& c ) { return --c == 0; } }

template<class Derived> template class intrusive_pointee_base { private: typedef intrusive_pointee_base self;

protected: intrusive_pointee_base(void) : reference_counter_(0) {} intrusive_pointee_base(self const&) : reference_counter_(0) {} intrusive_pointee_base operator=(self const&) { return *this } ~intrusive_pointee_base(void) {}

private: friend void intrusive_ptr_add_ref(const Derived * p) { IncrementPolicy::inc(&static_cast(p)->reference_counter_); }

friend void intrusive_ptr_release(const Derived * p) { if(!IncrementPolicy::dec( &static_cast<self const>*>(p)->reference_counter_)) delete p; }

mutable volatile long reference_counter_; };

Now you can add your own struct nt_mt_safe_increment { void inc( long& c ) { ::InterlockedIncrement(c); } bool dec( long& c ) { return ::InterlockedDecrement(--c) == 0; } }; Gennadiy

I did not do that, because shared_ptr does not. Counter should be a part of policy too, like: struct trivial_increment_policy { void inc( ) { ++c; } bool dec( ) { return --c == 0; } size_t c; } template class intrusive_pointee_base { private: typedef intrusive_pointee_base self; protected: intrusive_pointee_base(void) : reference_counter_() {} intrusive_pointee_base(self const&) : reference_counter_() {} self& operator=(self const&) { return *this } ~intrusive_pointee_base(void) {} mutable reference_counter_; };

On Wednesday 30 July 2008 16:03 pm, Alexander Gutenev wrote:

...

I want to use intrusive_ptr as a smart pointer to have reference counting without shared_ptr overhead.

I'm curious, could you be more specific about how your implementation has less overhead than shared_ptr? Do you mean it uses less memory? Compiles faster? Runs faster?

Less memory. The overhead of shared_ptr is allocation of another object which has reference count and deleter object. It is allocated in a separate block, hence memory overhead - that's the most noticeable when I have a lot of pointers to small objects. Also shared_ptr itself is double sized then. Also it is a bit more slow for allocation and deletion - but this is not noticeable in my case.

You confuse thing a bit I believe. The over head is not caused so much by the extra object itself as by the pointer to this object that have to reside inside every shared_ptr doubling it's size effectively.

Gennadiy

It depends, I think. Assume shared_ptr is used as an easy way to deal with polymorphic objects, like putting them into std::vector. Then most of the pointers would be unique. So vector data size is doubled, but this is not the most overhead. The most overhead is counter and deleter objects, those objects are larger than a single pointer, and each of them is stored in dedicated heap block. If shared_ptr is used really to share objects, then doubling pointer size may cause more overhead than counter and deleter.

Overhead of counter and deleter is exactly the same for both shared_ptr and intrusive_ptr - one per object (the fact that intrusive_ptr doesn't support Deleter at the moment is beside the point IMO - it should). Slight difference is that former is require additional new call.

Additional new call is not very little thing. Extra heap operation have its cost. Not sure for other platforms, but with VS2005, new is roughly malloc, malloc is roughly HeapAlloc, and Windows heap have overhead like rounding up to multiply of 16 bytes per HeapAlloc and using additional 16 bytes per HeapAlloc. The reason for polymorphic deleter in shared_ptr is, IMHO, that additional heap object is allocated anyway, so here polymorphic deleter is almost free sugar. For unique_ptr deleter is non-polymorphic, unique_ptr does not need additional object by itself, so here polymorphic deleter would be an expensive thing. For intrusive_ptr polymorphic deleter is too expensive too. As for non-polymorphic - this can be controlled by intrusive_ptr_add_ref implementation. Also, there's an alternative for custom non-polymorphic deleter: member operator delete. For PODs or not editable classes it cannot be added, but then inheritance from intrusive_pointee_base cannot be added too. If class is yours, why not write operator new/operator delete for it ?

On Wednesday 30 July 2008 16:03 pm, Alexander Gutenev wrote:

...

I want to use intrusive_ptr as a smart pointer to have reference counting without shared_ptr overhead.

I'm curious, could you be more specific about how your implementation has less overhead than shared_ptr? Do you mean it uses less memory? Compiles faster? Runs faster?

There's several ways to allocate reference counter: 1. In separate object allocated separately - this is shared_ptr 2. In the same buffer with object but not as a part of object - this is shifted_ptr 3. In the pointed object as a part of object - this is intrusive_ptr the way i'm trying to use it. The posted code is an implementation of what goes to the object. It actually not even necessary for a shared pointer to use an integer reference counting.

I'm getting a little off-topic, but actually shared_ptr supports #2 as well if you create it with make_shared/allocate_shared.

Interesting. Is this in Boost already ?