[boost] Re: call_traits aka parameter_traits

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-11-28 08:09:45

Ok, I'm going to group a bunch of replies together on this:

Beman -

>(It causes GCC 2.95.2 to loop; if anyone has a workaround please post
it here.)<

It does the same in Builder 4, however if you remove the second parameter,
and add it instead to a separate (hidden) implementation class, then it
works - provided that you also partially specialise for reference types -
ses the code I posted in my previous mail.

>Note name changes and typedef simplification.  I personally feel they
are an improvement, but nothing is finalized yet.<

Agreed - make the name as short as possible - either call_traits or
arg_traits maybe.

*****

Howard -

>I've been thinking about the pimpl problem too.  I think it may be the 
death of this suggestion.  This is like a huge ham in the butcher window. 
 Sure looks tasty, but when the spouse finds out how much you spent on it 
it may be your last meal.<

I like that analogy!

>And then for (small and fast) class iterators you would still have to 
specialize for type_traits, but not call_traits.  If there were some 
other benefit to type_traits, might be worth it.  But if type_traits only 
exists to support call_traits, I think not worth it.<

My own feeling is that type_traits is worth having in its own right - I've
been using it for the pattern matching code I've been working on - I'm sure
that if its in the library then people will start using it.  However I'm
not entirely happy with my current version - it still uses the double
underscored names of the SGI version (makes it easy to implement in terms
of the real SGI version when its available), but I think that can be fixed,
I'll have another look at it and post what I come up with  - unless anyone
else has a version out there?

*******

Dave -

>And has anyone done any actual _measurement_ to find out if the supposed
optimization is *really* an optimization? For example, contrary to
assumptions I've seen posted to this list, I would bet that long long is
really best passed by value most of the time. If you have a const T&
parameter and there's a non-inlined function call anywhere in the
function's
body, the parameter still has to be reloaded from memory after the call,
where it might otherwise have lived in a register or two.<

I agree that it probably makes little difference and that the result is
likely to be highly machine dependant, however the intent is that
call_traits (or whatever its called) should be no worse than existing
practice (using const T&), so if we provide some fairly conservative
defaults, uses can always tweek the class for a particular machine. Come to
that it could even be possible to write a shell configure script that
figures out where the cutoff is (by benchmarking "typical" situations with
the users compiler), whether or not its worth the effort though is another
issue :-)

*******

And finally....

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

In both cases they should never be worse than existing practice, on
compilers that don't support partial specialisation (VC6), they could be
defined to always reflect existing practice.

- John.