Boost logo

Boost :

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

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


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