[boost] type traits #3

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-01-16 07:39:18

Steve, Howard, Beman,

I've had a chance to take a closer look at Steve's updated type_traits
code, and I think on reflection I'm pretty happy with it, I've made some
minor changes and loaded them to the document vault
(http://www.egroups.com/docvault/boost/TypeTraits/version3?null=1) as
type_traits.hpp and type_traits_regress.cpp, along with some usage examples
in algo_opt_examples.cpp (more on that in a separate thread).

The main changes are:

1) changed the header file name to type_traits.hpp - I've found mixed case
filenames to be a real pain in past - having said that you can call it
whatever you like :-)
2) I've re-ordered some declarations to get the code to compile with g++,
it now compiles with the g++ -pedantic -ansi -Wall which I use as a kind of
portability litmus test.
3) As Howard has come around to using "value" for values and "type" for
types, I've changed the code to use "value" (again) for the static const
bool values. Steve if you feel strongly about this say so and we'll change
it back.
4) I've re-enabled the "automatic" detection of empty base classes - Steve
did you have a good reason for disabling this?  I realise that the code
fails for enum types, but without it, Howard's compressed_pair would seem
to be broken, unless you can persuade users to specialise is_empty for each
and every empty type (IMO this puts an unnecessary burden on the user).
5) I've added code for call_traits based on type_traits - maybe this should
be in utility.hpp rather than here? Howard do you have compressed_pair
ready to go based on type_traits?

I have some remaining issues/questions:

1) Steve, do you feel strongly about having both is_xxx and is_builtin_xxx
families - the reason I ask is that templates like is_integral duplicate
exactly the functionality already available from numeric_limits - removing
these would allow us to remove the dependency on <limits> also.

2) The is_fundamental versions make no sense to me, maybe I'm looking at
this wrong but a type is either fundamental or not - equivalent to your
is_standard_fundamental I think.

3) Howard - Steve's code does not "work" with cv-qualified types for
templates like is_integral<>, IMO this is the right way, but if you feel
really strongly the other way, make the change and I won't argue - Steve
what do you think?

Still to do,

We need a help file, and a "crippled" version of the code for those, well,
"crippled" compilers, I guess if we can nail down the basic header these
shouldn't be too hard.

Anyway, I think that's it,

- John.