Boost logo

Boost :

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


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

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:


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


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

>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
>working with it. I've got things on the way that depend on

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

- John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at