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: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
