[boost] Re: call_traits aka parameter_traits

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-11-28 16:32:47

John quoth:
> I've been wondering about Howard's size cutoff technique, is it worth
> splitting into two classes:
>
> template <class T>
> class ref_call_traits;
>
> template <class T>
> class value_call_traits;
>
> The first would only pass small POD types by value (as well as
> pointers/arrays/references being treated separately), the second would
> extend pass by value semantics to small non-POD types as well, possibly
> increasing the definition of "small" to 64-bit types.
>
> Usage: the first would be used where const T& is currently used
> (constructors, binder, adapters etc).
> the second would be used where T is currently passed by value (Allocators,
> iterators, functors etc).

1. I agree with Beman's inclination to keep things simple.

2. I don't see how value_call_traits would help. In general, if you need a
copy of the argument so you can modify it inside the called routine (and you
don't need the original value), simply passing by value incurs no cost. In
that case, no traits should be needed.

3. In general, I consider it poor style to modify the value of a parameter.
It's just too easy to refer to the parameter as though it hasn't been
modified, when in fact, it has. Of course, in certain cases there may be an
optimization to be gained by doing this, though cases where this would
matter seem rare to me. I'm wondering if this should impact our design
somehow...?

Beman writ:
>That leaves undecided how the user is to specify that a UDT should
>pass by value.  Either write a specialization for call_traits<> or
>via type_traits<>, I guess are the choices.

I don't understand this. How does type_traits come into the picture?
Are we talking about adding a boost::type_traits? If so, let me say this:
the problem with the name type_traits is that you sort of have to stick
everything about the type in there. Each time there's a new trait we want to
describe, we'll want to modify type_traits. I think it might be better to
break things down into smaller, separate trait packages.

-Dave