[boost] Re: Type Traits, Take Two

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 2000-01-11 10:24:32

>It is going to be the algorithm (method) writer that decides whether and
>how to use call_traits, not client code.  The algorithm writer will
>hopefully be aware of the aliasing issues you speak of and act
>accordingly.  For example, a method that best takes an argument by value
>to avoid aliasing problems will either not use call_traits, or perhaps
>use call_triats::value_type.

Indeed, I always hope for the best, but am often disappointed. I guess I
will reserve judgment on this until I see code for which this is shown to
make a difference, and could not have been written another way.

>Only algorithms that can take an argument either by const T or const T&
>would want to use call_traits::param_type.  And only those types that are
>both small and have trivial copy constructors should specialize to pass
>by const T.

Yes, this is where the platform specifics start messing up the trait's
code.

>That being said, optimization is IMO just a small (potential) side
>benefit of call_traits.  The real value of call_traits lies in the
>ability to handle array and reference types with ease.  The solution
>Dietmar Kühl presented in Kona for the make_pair("hi", ...) problem is a
>perfect application for the call_traits array capability.  And the same
>song and dance, but with references was proposed by Steve Cleary for the
>empty member optimization.  Then it took the genius of Beman Dawes to
>recognize the commonality and package the solution.

I think removing show stoppers is a different line of reasoning; one I am
happy with. I was just voicing concern that the way call_traits has been
discussed to date has been mostly in pursuit of optimistic optimisation
than in the solution of genuine problems.

Kevlin