[boost] Re: call_traits/type_traits

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-12-14 07:59:01

Howard, Steve -

OK here's a first draft of the "fundamentals", I haven't yet added the
call_traits or compressed_pair stuff on top of it - principally I'm still
ironing out some bugs - although I see different problems with Builder 4
and gcc2.95

Outstanding issues:

Builder 4 has some problems with some of the cv-traits stuff (but it seems
to work with gcc)
Builder's closure types aren't recognised as pointers - I can't figure out
a partial specialisation for these (it may not even be possible).
is_empty now works under Builder, but still fails under gcc (probably a
compiler problem).
All this is terminally broken under Visual C++ - I think we will have to
provide a separate implementation file (mostly non-working) for this
compiler - the changes are so pervasive I don't even want to think about
the macro approach.

Changes:

I've added macro hooks for built-in compiler support if should become
available.
I've deleted some templates that turned out not to be so "fundamental" and
added a couple that were previously missed.
One or two names have changed slightly to make their meaning clearer
(hopefully) - feel free to argue this - a search and replace is easy
enough:-)

To do:

I really want to track down the remaining bugs if I can, after that add the
call_traits/type_traits/compressed_pair wrapper stuff.

Howard -

many of your cv-modified specialisations aren't necessary - cv-modifiers
after a reference may not be allowed (gcc rejects this anyway I think),
cv-modifiers prior to a *,& or [] are unnecessary - a <T*> partial
specialisation will also catch things like "const int*" - in this case T =
const int.

Anyway, I think we are at the point where specialisations for built in
types should be redundant for call_traits/type_traits/compressed_pair (I
hope!).  However your type_traits::class_type enumerated value could be
hard to get right, without compiler support, I'll have to ponder on that...

BTW there is a problem with is_empty and hence compressed_pair: it looks as
though on compilers with 8-byte alignment, that empty structs take up
8-bytes - so "twinning" an empty struct with an int doesn't have as much an
effect as you may think it would - this is also why Steve's is_empty didn't
work on Builder 4.

- John.