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.