[boost] Re: [type traits] is_abstract_class submission

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
www.boost-consulting.com