Boost logo

Boost :

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.

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