Re: Overloading vs C++ 0x variadic templates
On Aug 14, 11:26 am, er <er.ci.2...@gmail.com> wrote:
In the above formulation, g(5) can be called (binds to the const&
overload). Indeed, it is this 2^n "explosion" that perfect forwardin=
g
is intended to avoid. Reference:
Yes, I'm aware that perfect forwarding caters to that, but here the
problem is with f, or rather the f--g interaction, not g alone. So
let me rephrase:
template<typename U> f(U&);
// n = 1
template<typename U> f(U&); // U = T or T const
template<typename T> g(T& t){ f( t ); }
template<typename T> g(T const & t){ f( t ); }
// etc. for n = 1,...,N
template<Args...> g_0x(Args&&...args)
{ f(std::forward<Args>( args )...); }
template<Args...> h_0x(Args&&...args)
{ f<Args...>( std::forward<Args>( args )... ); }
int main(){
g( 1 ); // ok
g_0x( 1 ); // invalid initialization of non-const ref from
temporary
h_0x( 1 ); // no matching function for call to f(int)
return 0;
}
What should be done to g/h _0x's definition for this to compile, and
if nothing can be done, what should be done to that of f?
If this is the behavior you need, here is how I would code it:
// n = 1
template<typename U> void f(U&) {} // U = T or T const
template<typename T> void g(T& t) { f( t ); }
template<typename T> void g(T const & t) { f( t ); }
// etc. for n = 1,...,N
template<typename ...Args> void g_0x(Args&&...args)
{ f(args...); }
template<typename ...Args> void h_0x(Args&&...args)
{ f( args...); }
int main(){
g( 1 ); // ok
g_0x( 1 ); // ok
h_0x( 1 ); // ok
return 0;
}
Explanation: inside of g_0x (and h_0x) each args is treated as an
lvalue. I.e., even though it is declared with an rvalue reference
type, /named/ references, even rvalue references, are lvalues. So in
the forwarding call to f(), f() is only seeing lvalues now.
This behavior is a safety feature to prevent variables from getting
"moved from" more than once. For more info see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#More%20on=
%20A&&
starting with:
"Even though named rvalue references ..."
Disclaimer: I'm pointing you to fairly old papers only because these
papers discuss the relevant details. Be forewarned that details of
the rvalue reference language feature have changed somewhat over the
years. If we stumble across a case where such a change matters, I'll
point it out.
-Howard