C++14 Template function forwarding reference deduced explicitly by pointer - c++

Explain, please, what's wrong with this code?
An unusual behaviour is that f3 is working, when deduced implicitly, but is not, when is forcely specialized.
template<typename T>
void f1(T x) {}
template<typename T>
void f2(T& x) {}
template<typename T>
void f3(T&& x) {}
int main()
{
int x = 0;
f1(x); // ok
f2(x); // ok
f3(x); // ok
f1<int>(x); // ok
f2<int>(x); // ok
f3<int>(x); // error
}
VS2017. Compilier message:
error C2664: "void f3(T &&)": unable to convert argument 1 from "int" to "T &&"
I thought I'm doing exactly the same specifying int explicitly. And only difference that deduction in this case f3(x); was done by compiler and in this one f3<int>(x); by me.

I'm not 100% sure, please someone correct me if I'm wrong:
Because in case of f3(x) the deduced type is f3<int&>( int& && ).

There is an Errror becuase l-values and l-values references cannot be used to initialize r-value references. R-values references can only be initialized with r-values only.
You can use PRETTY_FUNCTION to get the Function being called along with the arguments that are deduced.
f1(a); // ok deduces to void f1(T) [T = A *]
f2(a); // ok deduces to void f2(T &) [T = A *]
f3(a); // ok deduces to void f3(T &&) [T = A *&]
f1<A*>(a); // ok . No Deduction as T already specified void f1(T) [T = A *]
f2<A*>(a); // ok . No Deduction as T already specified to void f2(T) [T = A *]
f3<A*>(a); // Errror becuase l-values and l-values references
// cannot be used to r-value references.
// R-values references can only be initialized with r-values only.

Related

std::invoke - perfect forwarding functor

Trying to understand why the following example fails to compile:
#include <functional>
template <typename F>
void f1(F&& f)
{
std::forward<F>(f)("hi");
}
template <typename F>
void f2(F&& f)
{
std::invoke(f, "hi"); // works but can't perfect forward functor
}
template <typename F>
void f3(F&& f)
{
std::invoke<F>(f, "hi");
}
int main()
{
f1([](const char*) {}); // ok
f2([](const char*) {}); // ok
f3([](const char*) {}); // error
}
cppreference says the following about std::invoke:
Invoke the Callable object f with the parameters args. As by INVOKE(std::forward<F>(f), std::forward<Args>(args)...). This overload participates in overload resolution only if std::is_invocable_v<F, Args...> is true.
So why is f3 not equivalent to f1?
std::invoke is itself a function. In your case, its first parameter is a rvalue reference while f is a lvalue, so the error occurs.
INVOKE(std::forward<F>(f), std::forward<Args>(args)...) is executed after the function std::invoke is properly selected and called. Basically, your lambda function is passed as follows:
original lambda in main -> the parameter of f3 -> the parameter of std::invoke -> the parameter of INVOKE
So the std::forward in INVOKE(std::forward<F>(f), std::forward<Args>(args)...) is used in the last step, while you need to forward the lambda in the middle step (the parameter of f3 -> the parameter of std::invoke). I guess this is where your confusion comes.
Because you need to std::forward<F>(f) to std::invoke():
template <typename F>
void f3(F&& f)
{
std::invoke<F>(std::forward<F>(f), "hi"); // works
}
Consider the difference between these two calls:
void f(const int&) { std::cout << "const int&" << std::endl; }
void f(int&&) { std::cout << "int&&" << std::endl; }
int main()
{
std::cout << "first" << std::endl;
int&& a = 3;
f(a);
std::cout << "second" << std::endl;
int&& b = 4;
f(std::forward<int>(b));
}
The output is
first
const int&
second
int&&
If you remove the const int& overload, you even get a compiler error for the first call:
error: cannot bind rvalue reference of type 'int&&' to lvalue of type 'int'
The std::forward() is necessary for passing the correct type to std::invoke().
I guess you're getting this error:
note: template argument deduction/substitution failed:
note: cannot convert ‘f’ (type ‘main()::<lambda(const char*)>’) to type ‘main()::<lambda(const char*)>&&’
That's because inside the function f3, f is an L-value, but the invoke expects an R-value. For template argument deduction/substitution to work, the types have to match EXACTLY.
When you perfect forward f to invoke, this issue is resolved as you passed an R-value originally from outside f3.

Pass lambda as template function parameter

Why doesn't the following code compile (in C++11 mode)?
#include <vector>
template<typename From, typename To>
void qux(const std::vector<From>&, To (&)(const From&)) { }
struct T { };
void foo(const std::vector<T>& ts) {
qux(ts, [](const T&) { return 42; });
}
The error message is:
prog.cc:9:5: error: no matching function for call to 'qux'
qux(ts, [](const T&) { return 42; });
^~~
prog.cc:4:6: note: candidate template ignored: could not match 'To (const From &)' against '(lambda at prog.cc:9:13)'
void qux(const std::vector<From>&, To (&)(const From&)) { }
^
But it doesn't explain why it couldn't match the parameter.
If I make qux a non-template function, replacing From with T and To with int, it compiles.
A lambda function isn't a normal function. Each lambda has its own type that is not To (&)(const From&) in any case.
A non capturing lambda can decay to To (*)(const From&) in your case using:
qux(ts, +[](const T&) { return 42; });
As noted in the comments, the best you can do to get it out from a lambda is this:
#include <vector>
template<typename From, typename To>
void qux(const std::vector<From>&, To (&)(const From&)) { }
struct T { };
void foo(const std::vector<T>& ts) {
qux(ts, *+[](const T&) { return 42; });
}
int main() {}
Note: I assumed that deducing return type and types of the arguments is mandatory for the real problem. Otherwise you can easily deduce the whole lambda as a generic callable object and use it directly, no need to decay anything.
If you don't need to use the deduced To type, you can just deduce the type of the whole parameter:
template<typename From, typename F>
void qux(const std::vector<From>&, const F&) { }
Correct me if I am wrong, but template parameters deduction deduces only exact types without considering possible conversions.
As a result the compiler cannot deduce To and From for To (&)(const From&) because qux expects a reference to function, but you provide a lambda which has its own type.
You have left absolutely no chance to compiler to guess what is To. Thus, you need to specify it explicitly.
Also, lambda here needs to be passed by pointer.
Finally, this version compiles ok:
template<typename From, typename To>
void qux(const std::vector<From>&, To (*)(const From&)) { }
struct T { };
void foo(const std::vector<T>& ts) {
qux<T,int>(ts,[](const T&) { return 42; });
}
You're expecting both implicit type conversions (from unnamed function object type to function reference type) and template type deduction to happen. However, you can't have both, as you need to know the target type to find the suitable conversion sequence.
But it doesn't explain why it couldn't match the parameter.
Template deduction tries to match the types exactly. If the types cannot be deduced, deduction fails. Conversions are never considered.
In this expression:
qux(ts, [](const T&) { return 42; });
The type of the lambda expression is some unique, unnamed type. Whatever that type is, it is definitely not To(const From&) - so deduction fails.
If I make qux a non-template function, replacing From with T and To with int, it compiles.
That is not true. However, if the argument was a pointer to function rather than a reference to function, then it would be. This is because a lambda with no capture is implicitly convertible to the equivalent function pointer type. This conversion is allowed outside of the context of deduction.
template <class From, class To>
void func_tmpl(From(*)(To) ) { }
void func_normal(int(*)(int ) ) { }
func_tmpl([](int i){return i; }); // error
func_tmpl(+[](int i){return i; }); // ok, we force the conversion ourselves,
// the type of this expression can be deduced
func_normal([](int i){return i; }); // ok, implicit conversion
This is the same reason why this fails:
template <class T> void foo(std::function<T()> );
foo([]{ return 42; }); // error, this lambda is NOT a function<T()>
But this succeeds:
void bar(std::function<int()> );
bar([]{ return 42; }); // ok, this lambda is convertible to function<int()>
The preferred approach would be to deduce the type of the callable and pick out the result using std::result_of:
template <class From,
class F&&,
class To = std::result_of_t<F&&(From const&)>>
void qux(std::vector<From> const&, F&& );
Now you can pass your lambda, or function, or function object just fine.

Perfect forwarding and ambiguity of function-parameter binding

I am experimenting with the perfect forwarding feature of C++11. Gnu g++ compiler reports an ambiguity issue of function-parameter binding (the error is shown after the source code below). My question is why is it so, as following the function-parameter binding process I don't see the ambiguity. My reasoning is as follows: call to tf(a) in main() binds to tf(int&) since a is an lvalue. Then function tf forwards the lvalue reference int& a to function g hence the function void g(int &a) should be uniquely invoked. Thus I do not see the reason for ambiguity. The error disappears when the overloaded function g(int a) is removed from the code. This is strange as g(int a) cannot be a candidate for binding with int &a.
Here is my code:
void g(int &&a)
{
a+=30;
}
void g(int &a)
{
a+=10;
}
void g(int a) //existence of this function originates the ambiguity issue
{
a+=20;
}
template<typename T>
void tf(T&& a)
{
g(forward<T>(a));;
}
int main()
{
int a=5;
tf(a);
cout<<a<<endl;
}
Compilation g++ -std=c++11 perfectForwarding.cpp reports the following errors:
perfectForwarding.cpp: In instantiation of ‘void tf(T&&) [with T = int&]’:
perfectForwarding.cpp:35:7: required from here
perfectForwarding.cpp:24:3: error: call of overloaded ‘g(int&)’ is ambiguous
perfectForwarding.cpp:24:3: note: candidates are:
perfectForwarding.cpp:6:6: note: void g(int&&) <near match>
perfectForwarding.cpp:6:6: note: no known conversion for argument 1 from ‘int’ to ‘int&&’
perfectForwarding.cpp:11:6: note: void g(int&)
perfectForwarding.cpp:16:6: note: void g(int)
This is strange as g(int a) cannot be a candidate for binding with int &a.
That's not true. If you remove the g(int&) overload then g(int) will get called. When both are declared it is ambiguous, because both are viable candidates and require no conversions.
Adding on top of Jonathan Wakely's answer.
First of all, the issue has nothing to do with perfect forwarding and we can remove tf from the picture.
For the time being consider just this code:
void g(int) {}
int main() {
int a = 5; // a is an lvalue
g(a); // ok
g(std::move(a)); // std::move(a) casts a to an rvalue and this call is also ok
}
This illustrates that a function that takes a parameter by value can take both lvalues and rvalues.
Now suppose we add
void g(int &) {}
then the first call, g(a);, becomes ambigous because g(int &) can take non-const lvalues and nothing else. The second call, g(std::move(a)) is still ok and still calls g(int) because g(int &) can't take rvalues.
Now replace g(int &) with g(int &&). The latter function can take non-const rvalues only. Hence the call g(a) is ok and calls g(int). However, g(std::move(a)) is now ambiguous.
At this point it becomes obvious that if we have the three overloads together, then the two calls become ambiguous. Actually, there's no reason for having the three overloads. Depending on the type T, most often we have either
g(T) or
g(T&) or
g(const T&) or
g(const T&) and g(T&&).

binding a lvalue to a rvalue reference under MSVS2010

#include<iostream>
template<class T>
struct Foo
{
T v_;
Foo(T&& v):v_(std::forward<T>(v))
{
std::cout << "building Foo..\n";
}
};
int main()
{
int v;
Foo<int> foo(v);
std::cin.ignore();
}
visual c++ 2010 output :
error C2664: 'Foo<T>::Foo(T &&)' : cannot convert parameter 1 from 'int' to 'int &&'
Is it normal that I can't bind a lvalue to a rvalue reference ?
EDIT:
same thing for a function :
void f(int && v)
{
}
int v;
f(v); //won't compile
I'm a little bit confused because I think std::forward is usefull to detect if a method is called with a lvalue or a rvalue reference.
But it seems that we can't bind any lvalue into rvalue reference... at least without template parameter but I don't understand it very well
It's normal that calling a move constructor requires an r-value, not an l-value, since an l-value could be named after the move constructor runs, and using a moved-from value would evoke unintended behavior.

C++0x rvalue reference template argument deduction

Given GMan's deliciously evil auto_cast utility function concocted here, I've been trying to figure out why it doesn't compile for me when I'm trying to auto_cast from an rvalue (on MSVC 10.0).
Here's the code that I'm using:
template <typename T>
class auto_cast_wrapper : boost::noncopyable
{
public:
template <typename R>
friend auto_cast_wrapper<R> auto_cast(R&& pX);
template <typename U>
operator U() const
{
return static_cast<U>( std::forward<T>(mX) );
}
private:
//error C2440: 'initializing': cannot convert from 'float' to 'float &&'
auto_cast_wrapper(T&& pX) : mX(pX) { }
T&& mX;
};
template <typename R>
auto_cast_wrapper<R> auto_cast(R&& pX)
{
return auto_cast_wrapper<R>( std::forward<R>(pX) );
}
int main()
{
int c = auto_cast( 5.0f ); // from an rvalue
}
To the best of my ability I've tried to follow the C++0x reference collapsing rules and the template argument deduction rules outlined here, and as far as I can tell the code given above should work.
Recall that in pre-0x C++, it is not allowed to take a reference to a reference: something like A& & causes a compile error. C++0x, by contrast, introduces the following reference collapsing rules:
A& & becomes A&
A& && becomes A&
A&& & becomes A&
A&& && becomes A&&
The second rule is a special template argument deduction rule for function templates that take an argument by rvalue reference to a template argument:
template<typename T>
void foo(T&&);
Here, the following rules apply:
When foo is called on an lvalue of type A, then T resolves to A& and hence, by the reference collapsing rules above, the argument type effectively becomes A&.
When foo is called on an rvalue of type A, then T resolves to A, and hence the argument type becomes A&&.
Now when I mouse over the call to auto_cast( 5.0f ), the tooltip correctly displays its return value as auto_cast_wrapper<float>. This meaning that the compiler has correctly followed rule 2:
When foo is called on an rvalue of type A, then T resolves to A.
So since we have an auto_cast_wrapper<float>, the constructor should instantiate to take a float&&. But the error message seems to imply that it instantiates to take a float by value.
Here's the full error message, showing again that T=float correctly yet the T&& parameter becomes T?
main.cpp(17): error C2440: 'initializing' : cannot convert from 'float' to 'float &&'
You cannot bind an lvalue to an rvalue reference
main.cpp(17) : while compiling class template member function 'auto_cast_wrapper<T>::auto_cast_wrapper(T &&)'
with
[
T=float
]
main.cpp(33) : see reference to class template instantiation 'auto_cast_wrapper<T>' being compiled
with
[
T=float
]
Any thoughts?
You forgot to std::forward the T&& argument to the auto_cast_wrapper constructor. This breaks the forwarding chain. The compiler now gives a warning but it seems to work fine.
template <typename T>
class auto_cast_wrapper
{
public:
template <typename R>
friend auto_cast_wrapper<R> auto_cast(R&& pX);
template <typename U>
operator U() const
{
return static_cast<U>( std::forward<T>(mX) );
}
private:
//error C2440: 'initializing': cannot convert from 'float' to 'float &&'
auto_cast_wrapper(T&& pX) : mX(std::forward<T>(pX)) { }
auto_cast_wrapper(const auto_cast_wrapper&);
auto_cast_wrapper& operator=(const auto_cast_wrapper&);
T&& mX;
};
template <typename R>
auto_cast_wrapper<R> auto_cast(R&& pX)
{
return auto_cast_wrapper<R>( std::forward<R>(pX) );
}
float func() {
return 5.0f;
}
int main()
{
int c = auto_cast( func() ); // from an rvalue
int cvar = auto_cast( 5.0f );
std::cout << c << "\n" << cvar << "\n";
std::cin.get();
}
Prints a pair of fives.
Sorry for posting untested code. :)
DeadMG is correct that the argument should be forwarded as well. I believe the warning is false and the MSVC has a bug. Consider from the call:
auto_cast(T()); // where T is some type
T() will live to the end of the full expression, which means the auto_cast function, the auto_cast_wrapper's constructor, and the user-defined conversion are all referencing a still valid object.
(Since the wrapper can't do anything but convert or destruct, it cannot outlive the value that was passed into auto_cast.)
I fix might be to make the member just a T. You'll be making a copy/move instead of casting the original object directly, though. But maybe with compiler optimization it goes away.
And no, the forwarding is not superfluous. It maintains the value category of what we're automatically converting:
struct foo
{
foo(int&) { /* lvalue */ }
foo(int&&) { /* rvalue */ }
};
int x = 5;
foo f = auto_cast(x); // lvalue
foo g = auto_cast(7); // rvalue
And if I'm not mistaken the conversion operator shouldn't be (certainly doesn't need to be) marked const.
The reason it doesn't compile is the same reason for why this doesn't compile:
float rvalue() { return 5.0f }
float&& a = rvalue();
float&& b = a; // error C2440: 'initializing' : cannot convert from 'float' to 'float &&'
As a is itself an lvalue it cannot be bound to b. In the auto_cast_wrapper constructor we should have used std::forward<T> on the argument again to fix this. Note that we can just use std::move(a) in the specific example above, but this wouldn't cover generic code that should work with lvalues too. So the auto_cast_wrapper constructor now becomes:
template <typename T>
class auto_cast_wrapper : boost::noncopyable
{
public:
...
private:
auto_cast_wrapper(T&& pX) : mX( std::forward<T>(pX) ) { }
T&& mX;
};
Unfortunately it seems that this now exhibits undefined behaviour. I get the following warning:
warning C4413: 'auto_cast_wrapper::mX' : reference member is initialized to a temporary that doesn't persist after the constructor exits
It appears that the literal goes out of scope before the conversion operator can be fired. Though this might be just a compiler bug with MSVC 10.0. From GMan's answer, the lifetime of a temporary should live until the end of the full expression.