Consider this snippet of code, which uses the common idiom of having a function template construct an instance of a class template specialized on a deduced type, as seen with
There isn't a formal definition of "universal reference", but I would define it as:
A universal reference is a parameter of a function template with type [template-parameter]
&&
, with the intent that the template parameter can be deduced from the function argument, and the argument will be passed either by lvalue reference or by rvalue reference as appropriate.
So by that definition, no, the T&& v
parameter in foo
's constructor is not a universal reference.
However, the entire point of the phrase "universal reference" is to provide a model or pattern for us humans to think about while designing, reading, and understanding code. And it is reasonable and helpful to say that "When make_foo
calls the constructor of foo<U>
, the template parameter T
has been deduced from the argument to make_foo
in a way that allows the constructor parameter T&& v
to be either an lvalue reference or an rvalue reference as appropriate." This is close enough to the same concept that I would be fine moving on to the claim: "When make_foo
calls the constructor of foo<U>
, the constructor parameter T&& v
is essentially a universal reference."
Yes, both uses of std::forward
will do what you intend here, allowing member v_
to move from the make_foo
argument if possible or copy otherwise. But having make_foo(my_str)
return a foo<std::string&>
, not a foo<std::string>
, that contains a copy of my_str
is quite surprising....
make_foo
is in the same ballpark as "right", but foo
isn't. The foo
constructor currently only accepts a non-deduced T &&
, and forwarding there is probably not what you mean (but see @nosid's comment). All in all, foo
should take a type parameter, have a templated constructor, and the maker function should do the decaying:
template <typename T>
struct foo
{
T v_;
template <typename U>
foo(U && u) : v_(std::forward<U>(u)) { }
};
template <typename U>
foo<typename std::decay<U>::type> make_foo(U && u)
{
return foo<typename std::decay<U>::type>(std::forward<U>(u));
}
In C++14 the maker function becomes a bit simpler to write:
template <typename U>
auto make_foo(U && u)
{ return foo<std::decay_t<U>>(std::forward<U>(u)); }
As your code is written now, int a; make_foo(a);
would create an object of type foo<int &>
. This would internally store an int
, but its constructor would only accept an int &
argument. By contrast, make_foo(std::move(a))
would create a foo<int>
.
So the way you wrote it, the class template argument determines the signature of the constructor. (The std::forward<T>(v)
still makes sense in a perverted kind of way (thanks to @nodis for pointing this out), but this is definitely not "forwarding".)
That is very unusual. Typically, the class template should determine the relevant wrapped type, and the constructor should accept anything that can be used to create the wrapped type, i.e. the constructor should be a function template.