[boost] Re: Type Traits, Take Two

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-01-09 07:58:31

Howard -

><chuckle>  The circle is now complete. :-)<

I Know, I know!  The irony was not lost on me :-)

>I agree this does sidestep the value vs type issue.  But it does not 
sidestep the issue of whether cv-qualified types answer yes or no to 
is_type.  Either answer can be implemented in either design.  I still 
vote for cv-types answering yes to is_type (via either the separates or 
the enum design).<

I think it does - by specifying that exactly one bit is always set in the
"category" field we are saying that top level cv-modifiers are ignored in
that field and dealt with separately in the "modifiers" field.  I think it
is more intuitive this way than having is_pointer etc be true for
cv-qualified types, but then again I could just be being irrational :-)

>On code proliferation:  It seems to me that the trade off is a 
proliferation of structs vs a proliferation of enums.  Either works.  The 
interface seems to me to be about the same size either way.  You either 
have to remember the names of a bunch of structs:<

I think it reduces the amount of code slightly - to implement the
type_traits approach we would need only the "true fundamentals" and things
like is_integer, is_builtin_integer etc would all be redundant - I do take
your point about the number of enum's though.

>Personally I've grown fond of is_pointer<T>::value because it is less 
typing and fewer words to remember.  But my own first attempt at this 
stuff used enums much like you suggest.  And it worked fine.<

What "value" not "type"? <big grin>

>I'm not positive, but the enum design may be easier to port to compilers 
lacking the latest template goodies.<

Yes it may well be - whatever type_traits.hpp will be more or less broken
on compilers that don't implement partial specialisation - we should try
and provide a "safe fallback" version though.

Look: the enum based approach is *only* worth while considering if its
breaks the current logjam on the interface design.

- John.