Re: [boost] type traits proposal

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-02-22 08:22:31

John Maddock wrote:
> 
> >I think it is much more useful to provide is_class and treat unions as
> >classes in this case. Optionally we could add 'is_class_or_union' as
> >most compilers are able to implement this even when they cannot provide
> >is_class and is_union - and it would IMHO be a shame not to have this
> >trait.
> 
> Remember that this is a *temporary* latitude that has been granted - there
> is already one compiler (Metrowerks) that does the right thing, and gcc is
> likely to follow suite soon, no doubt others will as well.  IMO it is better
> to have the semantics we want to specified even if it means that we have to
> wait a while for it. 

Which means that you go for compiler-specific stuff to implement it? Or
is there some clever standard-conformant way I missed? Anyway, I agree
that it's best to get the correct behaviour and to encourage compiler
vendors to provide the necessary functionality.

> The reason for wanting is_class
> to exclude union types is simply that 90%+ of it's usage is to determine
> whether a type can be used as a base class or not - and unions can not.

Then I'm in the <10% party :) But even if only 10% would need the
distinction, that's far to much to justify that is_class would also
detect unions. Thus I think the proposal is best as it is now.

Regards, Daniel

PS: I guess your time is limited - as it seems to be for most people :)
- but I just want to make sure you haven't missed it: Somewhere at the
end of the ( heated :-9 ) discussion of is_class I proposed a small
patch which removes the warnings from the regression tests for the GCC -
at least it works for me :). Please consider applying it when you find
the time, thanks.

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de