[boost] Re: type traits #3

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-01-19 07:25:54

Howard,

>Yup.  What header do we want it in?  (code included below to get review 
started)<

I would favour call_traits and compressed_pair ending up in utility.hpp,
that seems to be the "natural" place for them, Beman?

>I feel most strongly that it is time to move forward with type_traits.  
>If I am the only one that does not like:

Ditto.

>I also still feel that numeric_limits should not be involved at all here, 
>but again, it is time to move forward.

Again ditto.

>Minor comments and proposed changes:

Thanks I'll go with all of those.

>I think references should be passed by non-const reference.  This 
>behavior can be very important in the selection of viable methods 
>(thinking auto_ptr here).

Yep,

>Also I completely clobbered your call_traits<array> :-)  But on shakey 
>ground so I would appreciate some feedback.

Shakey?  Heck it was positively quaking with my version :-)  This looks
better, but I suspect we'll need some concrete experience to get this
completely right.

Steve -

>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 think that it will work provided that the platform alignment is a power
of 2 and less than sizeof(our_test_class), the problem with the old one was
that if alignment was 8 bytes and the test class added a 4-byte int to the
8-byte empty structure, then we weren't filling out the empty struct
completely.  Obviously if the compiler doesn't support the empty-base-class
optimisation then neither is_empty nor compressed_pair will do anything
useful.

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

OK its easy to do so lets go with that as neither Howard nor I are entirely
happy with them.

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

Agreed, I was thinking that probably just a big table of
expressions/descriptions plus maybe a breif outline of some of the examples
for the documentation.

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

It's not hard to do, just ugly :-(  I'll put a separate header together for
that when everything else is nailed down (almost there now I think).

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

Ditto, I'm pretty busy right now, so if anyone wants to jump in just finish
this off go ahead, otherwise I can probably update the code at the
weekend...

- John.