Boost logo

Boost :

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
>> fallback.
> 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

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