Boost logo

Boost :

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. 

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk