12
votes

When programming in C++03, we can't pass an unnamed temporary T() to a function void foo(T&);. The usual solution is to give the temporary a name, and then pass it like:

T v;
foo(v);

Now, along comes C++0x - and now with rvalue references, a function defined as void foo(T&&) will allow me to pass a temporary. Which brings me to my question: since a function that takes an rvalue reference can take both rvalue references (unnamed temporaries) as well as lvalue references (named non-const references), is there any reason to use lvalue references anymore in function parameters? Shouldn't we always use rvalues as function parameters?

Granted, a function that takes an lvalue reference would prevent the caller from passing a temporary, but I'm not sure if that's a useful restriction.

2
It would be a very useful restriction if the routine tries to store off the address of the parameter for future use somewhere.T.E.D.

2 Answers

20
votes

"since a function that takes an rvalue reference can take both rvalue references (unnamed temporaries) as well as lvalue references (named non-const references)"

This is an incorrect statement. During the first iterations of the rvalue reference specification this was true, but it no longer is and is implemented at least in MSVC to comply with this later change. In other words, this is illegal:

void f(char&&);

char x;
f(x);

In order to call a function expecting rvalue references with an lvalue you must turn it into an rvalue like so:

f(std::move(x))

Of course, that syntax makes it quite clear what the difference between a function taking an lvalue reference and one taking an rvalue reference really is: an rvalue reference is not expected to survive the call. This is a big deal.

Now, you can of course make up a new function that does exactly what std::move does and then you "can" use rvalue references sort of like lvalue references. I thought about doing this for instance with a visitor framework I have when sometimes you simply don't care about any result of the visitor call, but other times you do and thus need an lvalue reference in those cases. With an rvalue reference I could get both...but it's such a violation of the rvalue reference semantics that I decided it was a bad idea.

Your statement may be a confusion based upon this:

template < typename T >
void f(T&&);

char x;
f(x);

This works, but not because you are passing an lvalue as an rvalue reference. It works because of reference decay (also new in C++0x). When you pass an lvalue to such a template it actually gets instantiated like so:

void f<char&>(char&&&);

Reference decay says that &&& turns into & so then the actual instantiation looks like this:

void f<char&>(char&);

In other words, you're simply passing an lvalue by reference...nothing new or special about that.

Hope that clears things up.

0
votes

It's a useful restriction if that temporary must be actively disposed of, say a pointer to new memory or a limited resource like a file handle. But needing to pass those back smells more of "bad design" than it does of "useful restriction."