From: Howard Hinnant (hinnant_at_[hidden])
Date: 1999-12-10 18:06:03
Beman Dawes wrote on 12/10/99 5:23 PM
>Howard, John, Steve,
>I lost track of the call_traits/type_traits discussion. Was any
>conclusion reached? Could someone summarize where we stand?
My day job became urgent and I've had to drop work on it. But the
interest is still there. Maybe over the weekend...
My view of where we stand:
Steve proposed a bunch of separate classes that look promising (at least
to me) as a replacement for type_traits. It's unclear at this point if
Steve's submission is a subset, superset or whatever of what we want. A
major technical roadblock is not being able differentiate enums from
classes from unions (especially the enum part, I could probably live with
classes and unions being indistinguishable). Still, even without the
enum ability, the package looks very good. Lightyears ahead of where we
are without such support. I'll refer to this set of classes as "the
fundamentals" instead of type_traits.
call_traits (imo) can be easily implemted in terms of "the fundamentals"
without the need to have an explicit list of built in types. My opinion
on the interface of call_traits stands at:
template <typename T, possibly defaulted args to help implement>
value_type is essentially Steve's remove_reference.
reference is esstentially Steve's add_reference.
I believe array types are exceptions to the above two statements.
param_type is typically set to one of the other three typedefs, depending
upon the type.
Lacking from the original call_traits proposal was the ability to handle
cv-qualified types. With Steve's fundamentals, this should be no problem
(but I haven't done the work).
What this means to me:
While the fundamentals are big unknown for me right now, call_traits
isn't as I've implemented it without help of the fundamentals and have
discovered it much more than mildly useful. (The implementation is a
giant pain in the a** that proper fundamentals should relieve).
I've used call_traits and fundamentals/type_traits to work over
empty_member, which I now call compressed_pair in my own code.
compressed_pair depends critically upon call_traits as I've expressed it
above. It acts just like pair except that it will optimize empty
members. Members of compressed_pair can be classes or built-in types,
but not enums (currently).
I've built alloc_ptr on top of compressed_pair and call_traits. It's
auto_ptr on steroids and I'm really excited about it.
I'm currently building a hash container (my day job, finally!) which is
making extensive use of alloc_ptr, compressed_pair, and probably
So I'm fairly dug in on (the interface of) call_traits, but not
ironically type_traits (the fundamentals). The only stuff I have that
depends upon the interface of the fundamentals is call_traits and
compressed_pair, and in each case those dependencies are implementation
details that can easily be changed.
My being dug in on call_traits doesn't necessarily mean it is the final
word for Boost. I say it more to express that the above interface is
being heavily used in my current development, and proving itself nicely.
>It would be a shame to let this discussion just die; we have seen a
>lot of good ideas and need to synthesize them into an actual boost
>library everybody can feel good about supporting.
Before call_traits is set in stone, I think the fundamentals need to be
worked out. They would seem to be very useful for the implementation of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk