Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-21 12:49:32

From: "Peter Dimov" <pdimov_at_[hidden]>

> From: "David Abrahams" <dave_at_[hidden]>
> >
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >
> > > My reasoning was that has_virtual_destructor (whenever it appears in
> > > type_traits) would be approximated with is_polymorphic (which is yet
> > > appear in type_traits too) anyway.
> >
> > I'm not sure we want a trait that gives false positives on all
> > implementations.
> Do we not want std::has_virtual_destructor at all? Or do we not want
> boost::has_virtual_destructor at all? Or do we not want the particular
> implementation that assumes that polymorphic types have virtual
> Why are false positives a problem when the alternative (as in our case)
> to not check at all, or to check for is_polymorphic?

I don't know, really. As I said: "I'm not sure..."
Vague misgivings only. Call me a FUD-dy duddy.

> > > That aside, making our implementation detect the case implies a new
> > > dependency on config.hpp (member templates) and on
> > > type_traits/has_virtual_destructor.hpp. Is scoped_ptr<Base>(new
> > a
> > > common mistake? I think not, but I might be wrong.
> >
> > If it's worth storing an extra pointer for every shared object in the
> > shared_ptr case, surely it's worth detecting this one at compile time?
> There are so many things wrong with this sentence. :-)
> Derived) is a feature. Comparing a feature with a required diagnostic
> fair. The extra pointer supports much more than this particular

Tell me. I'm trying to describe the evolution of shared_ptr now, and it
seems to me that the extra pointer supports:

    Derived->Base conversion when there's no virtual destructor

What else?

> Not that I'm against detecting errors at compile time or something, but
> always considered dependencies a problem.

Remember, it's not in type_traits yet ;-)


           David Abrahams * Boost Consulting
dave_at_[hidden] *

Boost list run by bdawes at, gregod at, cpdaniel at, john at