Re: [boost] [intrusive_ptr] atomic ref counting?

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2006-04-18 13:25:26

Eric Niebler wrote:
> You're right, because in xpressive alone I use counted_base in no less
> than 3 places where the virtual destructor would be needless overhead!
> Clearly, it can't be all that uncommon.

I did not use the CRTP in statechart for the following reasons:
- If you have a hierarchy that is several levels deep, then needing to 
propagate the Derived parameter through all those levels will lead to 
considerable code bloat if you have many most-derived classes. I faintly 
remember someone saying that compilers should be able to detect and 
automatically reduce such code-bloat but I'm sceptical whether most of 
them do that today. To avoid the bloat you could have your most-derived 
classes inherit from counted_base *and* BaseClass but this also means 
that you can no longer use intrusive_ptr<BaseClass>.
- If you have full control over object construction and destruction, you 
can get away with defining the add_ref & release functions for the 
derived classes or class templates (scroll right to the bottom in both 
files):
<http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/statechart/detail/state_base.hpp?rev=1.22>
<http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/statechart/simple_state.hpp?rev=1.35>

This avoids code bloat by only duplicating the release function but 
still does not require any virtual destructors.

> I thought NeedsLocking was reasonable until I noticed that
> atomic_count is a typedef for long if BOOST_HAS_THREADS is not
> defined. That should be good enough, IMO.

Sometimes it isn't good enough. I have a scenario where I know that 
counted_base subclass objects will *always* be accessed by one and the 
same thread. The program is still multithreaded, so doing away with 
NeedsLocking would generate unnecessary overhead here.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.