Resending. It's been a while, and I don't want this issue to get lost. Peter? Eric Niebler wrote:
Peter Dimov wrote:
Eric Niebler wrote:
Peter Dimov wrote:
I can't help but think that even if I did add the above, you wouldn't use it because of the virtual destructor,
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.
It may be common. The point is that we need to settle on a single version of boost::counted_base. The virtual destructor version does have its benefits: it's easier to understand and use (CRTP can be a bit hard to swallow) and it allows intrusive_ptr<counted_base> to be used as the intrusive version of shared_ptr<void> and void* (with the additional benefit of a working dynamic_cast.)
counted_base is somewhat bicycle sheddish and I've considered adding one as documentation rather than code. But one problem with that is atomic_count being in detail. :-)
I'm confident that we can settle on a single design, and we should. I'd rather include your counted_base with a virtual than leaving it in the docs where people will ignore it and it won't get used.
How about this:
template<typename Derived> struct basic_counted_base { ... my counted_base implementation here ... ... with no virtual destructor ... };
struct counted_base : basic_counted_base<counted_base> { virtual ~counted_base() {} };
That way we get the best of both worlds.
The following program exposes the problem for me with vc7.1, vc8 and gcc 3.4.4. If you comment out the friend functions and uncomment the global free functions, the problem goes away. I don't understand it -- is some name look-up subtlety at play here?
I don't understand it either. Comeau/EDG compiles it. A non-template counted_base doesn't have this problem, FWIW.
Confirmed. Also, the problem doesn't happen when impl in my example is a non-template. Looks like compiler bugs, but it's strange that both VC and gcc reject it with similar error messages. <shrug>
-- Eric Niebler Boost Consulting www.boost-consulting.com