21

I'm having trouble overloading a function to take a value either by const reference or, if it is an rvalue, an rvalue reference. The problem is that my non-const lvalues are binding to the rvalue version of the function. I'm doing this in VC2010.

#include <iostream> #include <vector> using namespace std; template <class T> void foo(const T& t) {cout << "void foo(const T&)" << endl;} template <class T> void foo(T&& t) {cout << "void foo(T&&)" << endl;} int main() { vector<int> x; foo(x); // void foo(T&&) ????? foo(vector<int>()); // void foo(T&&) }

The priority seems to be to deduce foo(x) as

foo< vector<int> & >(vector<int>& && t)

instead of

foo< vector<int> >(const vector<int>& t)

I tried replacing the rvalue-reference version with

void foo(typename remove_reference<T>::type&& t)

but this only had the effect of causing everything to resolve to the const-lvalue reference version.

How do I prevent this behaviour? And why is this the default anyway - it seems so dangerous given that rvalue-references are allowed to be modified, this leaves me with an unexpectedly modified local variable.

EDIT: Just added non-template versions of the functions, and they work as expected. Making the function a template changes the overload resolution rules? That is .. really frustrating!

void bar(const vector<int>& t) {cout << "void bar(const vector<int>&)" << endl;} void bar(vector<int>&& t) {cout << "void bar(vector<int>&&)" << endl;} bar(x); // void bar(const vector<int>&) bar(vector<int>()); // void bar(vector<int>&&)
Improve this question
3
  • What happens when you make x const? What happens when you use x after the other call to foo? Commented Oct 13, 2011 at 0:42
  • It is possible to arrange for deduced T&& to bind only to rvalues. See ideone.com/XSBifq . But I wouldn't recommend this. The accepted answer, i.e. don't use overloading like this, is the right approach. Commented May 10, 2013 at 23:52
  • channel9.msdn.com/Shows/Going+Deep/… Commented Aug 12, 2014 at 6:25

2 Answers 2

Reset to default
26

When you have a templated function like this you almost never want to overload. The T&& parameter is a catch anything parameter. And you can use it to get any behavior you want out of one overload.

#include <iostream> #include <vector> using namespace std; template <class T> void display() { typedef typename remove_reference<T>::type Tr; typedef typename remove_cv<Tr>::type Trcv; if (is_const<Tr>::value) cout << "const "; if (is_volatile<Tr>::value) cout << "volatile "; std::cout << typeid(Trcv).name(); if (is_lvalue_reference<T>::value) std::cout << '&'; else if (is_rvalue_reference<T>::value) std::cout << "&&"; std::cout << '\n'; } template <class T> void foo(T&& t) { display<T>(); } int main() { vector<int> x; vector<int> const cx; foo(x); // vector<int>& foo(vector<int>()); // vector<int> foo(cx); // const vector<int>& }
Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Yes, you've got it. Although I would have worded it differently: && in a non-template function means "move-semantics", && in a template function means "perfect forwarding"
Fair enough, I guess, but that does frustrate me a bit. I can see issues arising out of the lack of unity between semantics.
Fair enough. Me and some other guys (Peter and Dave) were trying to kill two birds with one stone with the introduction of rvalue references: move semantics and perfect forwarding. At the time (2002) we were thinking that a minimal change to the language with little or no backwards incompatibility and accomplish more than one impossible task would be a good thing. But had we been designing with a clean slate, certainly cleaner solutions seem plausible. Certainly if this frustration increases, one should restrict oneself to the C++98/03 subset, and thus this issue will not arise.
<sigh> <off topic> and my sincerest condolences to the family of Dennis Ritchie.
Well, yes, but that's a pretty poor option. It just means you have to remember that need to be very careful when attempting to templacise any function with rvalue references. Unfortunately, if you forget it usually will still compile just fine, except you'll be killing all objects you call that function with! I could easily see that leading to subtle and hard-to-find bugs, especially if you are used to the C++03 templates that always generated equivalent functions.
|
13

In order for T&& to bind to an lvalue reference, T must itself be an lvalue reference type. You can prohibit the template from being instantiated with a reference type T:

template <typename T> typename std::enable_if<!std::is_reference<T>::value>::type foo(T&& t) { cout << "void foo(T&&)" << endl; }

enable_if is found in <utility>; is_reference is found in <type_traits>.

The reason that the overload taking T&& is preferred over the overload taking a T const& is that T&& is an exact match (with T = vector<int>&) but T const& requires a qualification conversion (const-qualification must be added).

This only happens with templates. If you have a nontemplate function that takes a std::vector<int>&&, you will only be able to call that function with an rvalue argument. When you have a template that takes a T&&, you should not think of it as "an rvalue reference parameter;" it is a "universal reference parameter" (Scott Meyers used similar language, I believe). It can accept anything.

Allowing a T&& parameter of a function template to bind to any category of argument is what enables perfect forwarding.

Improve this answer

3 Comments

So whenever you templacise a function with an rvalue reference, you need to always remember to manually remove the reference overload?
@Ayjay No, usually one template that makes use of perfect forwarding is enough. Since it accepts anything (see Howard's answer) and the value category as well as the cv qualifiers of the argument are preserved, you rarely need another overload.
I have been trying this, and the issue I'm finding is that fighting compile errors is hard. Even though the actual code that would be executed is syntatically correct, some of the other if-conditions have invalid syntax. This is frustrating me, and I may use enable-if to restore the non-template rvalue overload rules so that I can write the functions the same as if they were not templacised.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.