[boost] Re: parameter_traits aka constructor_parameter

From: Beman Dawes (beman_at_[hidden])
Date: 1999-11-26 15:44:20

At 07:55 AM 11/25/99 -0500, John Maddock wrote:

>OK so we have parameter_traits, and use it as:
>
>template <class T>
>void foo(typename parameter_traits<T>::parameter_type param)
>{
>}
>
>Clearly we need the typedef "parameter_type", however the "original
type"
>which you have as "decayed_type" appears to be unnessary - because
of the
>way the function is declared we alway have access to this anyway -
in this
>case as the template parameter T - but even if its some other more
complex
>type, the body of foo can always tell what it is.

This question turns on what type T is for both function and class
templates when an array type is supplied.  Is T the original array
type, or has it been decayed to a pointer?  If it is the original
type (and Dietmar, at least, says it should be) then we may wish to
know the type after decay.  Probably more an issue with template
classes than template functions.

That was the motivation.  I tried to confirm this via testing, but
run into compiler problems.

>There is one member which may be appropriate though - something
like:
>
>static const bool is_specialised = true/false;
>
>So that the function body can tell whether we have converted the
"value" to
>a reference (is_specialised is false), or whether we have the value
>directly (is_specialised is true).  To be honest I can't think of
any
>immediate uses - but I'm sure there are some!
>
>Finally, I can think of two immediate applications for
parameter_traits:
>
>To replace const T&, for example in binders/adaptors.
>
>To replace iterators passed by value in algorithms:
>
>currently it is usual to write:
>
>template <class iterator>
>void foo(iterator i, iterator j){ /*...*/ }
>
>but if foo can be inlined, and iterator is a class type rather than
a
>pointer, then we lose effeciency because inline expansion will be
>prohibited, so:
>
>template <class iterator>
>void foo(typename parameter_traits<iterator>::parameter_type i,
typename
>parameter_traits<iterator>::parameter_type j){ /*...*/ }
>
>may be better, albeit at the expense of readablity.....
>
>Unfortunately, having experimented with this, template argument
deduction
>fails in such cases - and thinking about it I can't see how it could
have
>succeeded, specifying the template parameters explicitly works (as
you
>would expect), but this isn't really much use - so it looks like the
>technique is limited to member functions.

Yes, I tripped on deduction too.  But by having the initial function
call a helper function with explicit template arguments, you can work
your way around that.  Although I am not sure if that is worth doing.

--Beman