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
* 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
* 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.
>But our current version will cut out at 256 bytes. That's the only issue
>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 :-(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk