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