Re: [boost] call_traits

From: Graeme Prentice (gp.kiwi_at_[hidden])
Date: 2005-09-26 04:33:42

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Simon Buchan
> 
> Graeme Prentice wrote:
> <snipped big header>

Six lines is big?

> >>#include <boost/call_traits.hpp>
> >>
> >>template < typename P1 >
> >>void foo ( typename ::boost::call_traits < P1 >::param_type p1 )
> >>{
> >>}
> >>
> >>int main (  )
> >>{
> >>    foo ( 42 ); // error here
> >>    return 0;
> >>}
> > 
> > This is the infamous non-deduced context.  A nested name specifier
> > (call_traits) is a non-deduced context so P1 cannot be 
> deduced.  You have to
> > write foo<int>(42).  This is like an invisible cast, so you 
> have to remember
> > to change all the explicit type specifiers if you change 
> the type of an
> > argument being passed in such a function.
> 
> You mean:
>      template <class T>
>      void foo( typename bar<T>::baz froble) {...}
> is fine, but:
>      template <class T>
>      void foo( typename bling::bar<T>::baz froble) {...}
> isn't? That sounds like a language flaw!

No, neither is fine.  bar<T> is a non-deduced context in both cases.  What
makes you think the first case is fine?
There's a good reason for this restriction even though it's a surprise when
you first meet it.

> 
> >>(Background info: I would like to use this technique to generate 
> >>optimized forwarding functions that do not know anything about the 
> >>function being forwarded to.  Overloads taking any number of params 
> >>would be generated with the boost preprocessor library.)
> >>
> >>-Jason
> > 
> > It might be better to write specializations for foo rather 
> than specify the
> > types at the point of call.
> > 
> > Graeme
> 
> Doesn't that defeat the point of a forwarding function? I agree that 
> it's better than most of the alternatives, though.

How does it defeat the point of a forwarding function?

Do you mean it contradicts the requirement of the forwarding function not
knowing anything about the function being forwarded to?  If the
specializations (or overloads) provided are the same as the call_traits
ones, then the forwarding function still doesn't know anything about the
function being forwarded to.  Chances are the forwarding function will be
inlined and the parameter types of the forwarding function won't matter so a
single forwarding function that passes by value might do.  Using call_traits
might even be less efficient.

Graeme