[boost] Re: type traits #3

From: scleary_at_[hidden]
Date: 2000-01-17 14:16:00

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

No problem here.

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

Again, no problem.  I'm setting up my new home system with Debian, so
hopefully soon I'll be checking my code against g++ as well as BCB4.

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

No, no problem.  That's the way we had it originally.

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

Do we have any guarantee that it will work on any system?  I guess I still
don't know why we need an array of int's instead of just one.  Even with the
array, are we still guaranteed to sidestep alignment issues?

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

No, I don't care.  I included them just so that user code could have all
needed type traits come from one place with similar syntax.  They're not
important; we can remove them, and the dependency on <limits> as well.

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

'fundamental' has a strict definition in the Standard: 'arithmetic' types or
void.  I've "extended" the definition in the same way that I "extended" the
definition of 'arithmetic' in the Standard.  Now we have
is_standard_arithmetic, which is arithmetic types strictly defined by the
Standard; and is_builtin_arithmetic, which is all arithmetic extensions
supplied by the compiler (long long, etc.).  So the parallel to that would
be to have is_standard_fundamental, which is is_standard_arithmetic or void;
and is_builtin_fundamental, which is is_builtin_arithmetic or void.

I have no purpose in mind for is_builtin_fundamental (or several of the
other types included in type_traits); most of them just grew out of
extending the Standard definitions in the manner above.  If you think they
clutter up the code or unnecessarily complicate matters, they can be
removed.

> 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?
>

Again, the type_traits were just taken from a strict interpretation of the
Standard.  This can be confusing, because 'arithmetic' tests will reject
cv-qualifications, but 'scalar' tests will accept them.  The other option is
to define what exactly will pass for each type_trait, and make this well
documented.  Whichever is easier for users; I don't care, as long as it's
well-documented.

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

The beginning of the header is an obvious starting point for the docs.  It
should be stripped off when the docs are complete.

Sorry, I don't have a brain-damaged M$ compiler, so I can't help with the
crippling of the code.  ;)

I agree with Howard; we need to get type_traits nailed down so we can start
working with it.  I've got things on the way that depend on
compressed_pair/call_traits.

        -Steve