[boost] type traits #4

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-01-22 07:50:43

Beman, Steve, Howard - 

I've updated the type_traits files with the modifications suggested so far,
and put them into a tentative directory structure (see attatched zip):

*  I've assumed that this is going to end up in the utility section is this
correct?
*  I've added crippled versions of the headers for crippled compilers to
use, in order to simplify things these are as separate versions, the
headers <boost/type_traits.hpp> etc have become just place-holders that
include either one or the other of the real header versions.
*  I've split call_traits off into its own header - however should
call_traits and compressed_pair really be in <boost/utility.hpp>?  What
does everyone think?
*  I couldn't get compressed_pair to compile with C++ Builder at all, so
for now this compiler gets the crippled version - Howard - I've made one or
two (very minor) tweeks to compressed_pair.hpp to get it compile cleanly
with gcc.
*  I've added tentative copyright declarations to all files that didn't
have one before - can everyone who's contributed please check these?  In
particular have I left anyone out?  Howard - the copyright declaration for
compressed_pair needs finishing off.

There's still no documentation - I'll try and work on the type-traits docs
over the weekend - anyone want to tackle call_traits/compressed_pair?

>One potential advantage of using is_empty instead of is_class is that 
>swap can explicitly optimize away the swap call for the empty member if 
>is_empty is used.  The compiler may do this as well, depending upon the 
>quality of the compiler.

Good point.

>But our current version will cut out at 256 bytes.  That's the only issue
I
>have with it.  I would like to, if possible, write self-maintaining code
:),
>so we don't have to re-visit this way down the line after we all forgot
>about it :).

We never create an instance of that struct though - just measure it's size,
it could be a million bytes and it would make no difference - I take your
point about self-maintaining code though - this is a tough one, I suspect
whatever we do some compiler will probably break it eventually :-(

- John.