Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-01-08 14:04:26

John Maddock wrote on 1/8/2000 7:55 AM
>However - I worry about the complexity of type_traits and the number of
>templates we seem to have acquired - in particular is_integral duplicates
>numeric_limits<>::is_integral exactly - as implemented they are required to
>always give the same result. Given that we are using section 3.9 as a
>guide could we not depreciate is_builtin_integral and make is_integral
>behave as is_builtin_integral does now? As an asside I think with this
>change we could also remove the dependance on numeric_limits<> completely
>(without increase in code size), and in doing so improve portability -
>there does seem to be a problem with <limits> implementations in general.

I agree with this general sentiment. I see different semantics between
the type traits is_integral and the numeric_limits is_integral.

>OK now I'm going to throw in a radical idea - so feel free to shoot me
>What if we bring back a type traits class as follows, which would be the
>only documented member of type_types.hpp:

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

>Implementation would use a simplified form of our existing fundamentals
>(which could be moved into the implementation namespace) - I think there is
>an oportunity here both to reduce the amount of code, and the number of
>classes, and work around the arguments we've been having about whether a
>value can be called "type", and whether a cv-qualified int is an integral
>type or not. On the other hand maybe not: I don't want to swap one lot of
>indecision for another :-)

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).

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:


or the names of a bunch of enums:


So the question comes down to which has the best interface:



type_traits<T>::category == is_pointer

I can easily imagine that either would be preferred by different

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.

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


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