From: David Abrahams (dave_at_[hidden])
Date: 2004-01-12 10:27:44
"John Maddock" <john_at_[hidden]> writes:
>> I think we really ought to have something more descriptive ;-)
>> > Older compilers would bypass is_abstract_class<> when macro
>> > is defined.
>> We should do
>> mpl::and_<is_class<T>, mpl::not_<is_POD<T> > > as a
> I don't understand that - how is a type that is a non-POD class the same
> thing as an abstract type? Wouldn't is_polymorphic be a better
> approximation? In any case I think it is up to the user of is_abstract to
> decide what fallback to use if it's not supported - there's no obvious
> "right" answer to what the fallback should be IMO.
The point is that the way type traits works right now, it makes the
"conservative assumption" about a type's capabilities when those can't
be determined. See for example has_nothrow_copy_constructor.
is_abstract is essentially a test for what can be done with a class,
and if you can't make a determination, any non-POD class must be
assumed to be abstract.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk