{"id":4643,"date":"2009-02-03T12:27:00","date_gmt":"2009-02-03T12:27:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2009\/02\/03\/rvalue-references-c0x-features-in-vc10-part-2\/"},"modified":"2022-01-19T19:07:45","modified_gmt":"2022-01-19T19:07:45","slug":"rvalue-references-c0x-features-in-vc10-part-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/rvalue-references-c0x-features-in-vc10-part-2\/","title":{"rendered":"Rvalue References: C++0x Features in VC10, Part 2"},"content":{"rendered":"

Part 1<\/span><\/a> of this series covered lambdas<\/b>, auto<\/b>, and static_assert<\/b>.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Today, I’m going to talk about rvalue references<\/b>, which enable two different things: move semantics<\/b> and perfect forwarding<\/b>.\u00a0 This post will be long, because I’m going to explain how rvalue references work in great detail.\u00a0 They’re initially very confusing because they distinguish lvalues from rvalues, which very few C++98\/03 programmers are extensively familiar with.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Fear not, for using rvalue references is easy, much easier than it initially sounds.\u00a0 Implementing either move semantics or perfect forwarding in your own code boils down to following simple patterns, which I will demonstrate.\u00a0 And it’s definitely worth learning how to use rvalue references, as move semantics can produce order of magnitude<\/i> performance improvements, and perfect forwarding makes writing highly generic code very easy.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

lvalues and rvalues in C++98\/03<\/span><\/span><\/b><\/p>\n

 <\/p>\n

\u00a0<\/span><\/p>\n

In order to understand rvalue references in C++0x, you must first understand lvalues and rvalues in C++98\/03.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

The terminology of “lvalues” and “rvalues” is confusing because their history is confusing.\u00a0 (By the way, they’re just pronounced as “L values” and “R values”, although they’re written as single words.)\u00a0 These concepts originally came from C, and then were elaborated upon by C++.\u00a0 To save time, I’ll skip over their history, including why they’re called “lvalues” and “rvalues”, and I’ll go directly to how they work in C++98\/03.\u00a0 (Okay, it’s not a big secret: “L” stands for “left” and “R” stands for “right”.\u00a0 But the concepts have evolved since the names were chosen, and the names aren’t very accurate anymore.\u00a0 Instead of going through the whole history lesson, you can consider the names to be arbitrary like “up quark” and “down quark”, and you won’t lose anything.)<\/span><\/p>\n

\u00a0<\/span><\/p>\n

C++03 3.10\/1 says: “Every expression is either an lvalue<\/i> or an rvalue<\/i>.”\u00a0 It’s important to remember that lvalueness versus rvalueness is a property of expressions, not of objects.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Lvalues name objects that persist beyond a single expression.\u00a0 For example, <\/span>obj , <\/span>*ptr , <\/span>ptr[index] , and <\/span>++x are all lvalues.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Rvalues are temporaries that evaporate at the end of the full-expression in which they live (“at the semicolon”).\u00a0 For example, <\/span>1729 , <\/span>x + y , <\/span>std::string(“meow”) , and <\/span>x++ are all rvalues.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Notice the difference between <\/span>++x and <\/span>x++ .\u00a0 If we have <\/span>int x = 0; then the expression <\/span>x is an lvalue, as it names a persistent object.\u00a0 The expression <\/span>++x is also an lvalue.\u00a0 It modifies and then names the persistent object.\u00a0 However, the expression <\/span>x++ is an rvalue.\u00a0 It copies the original value of the persistent object, modifies the persistent object, and then returns the copy.\u00a0 This copy is a temporary.\u00a0 Both <\/span>++x and <\/span>x++ increment <\/span>x, but <\/span>++x returns the persistent object itself, while <\/span>x++ returns a temporary copy.\u00a0 That’s why <\/span>++x is an lvalue, while <\/span>x++ is an rvalue.\u00a0 Lvalueness versus rvalueness doesn’t care about what an expression does<\/i>, it cares about what an expression names<\/i> (something persistent or something temporary).<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

If you want to build up intuition for this, another way to determine whether an expression is an lvalue is to ask “can I take its address?”.\u00a0 If you can, it’s an lvalue.\u00a0 If you can’t, it’s an rvalue.\u00a0 For example, <\/span>&obj , <\/span>&*ptr , <\/span>&ptr[index] , and <\/span>&++x are all valid (even though some of those expressions are silly), while <\/span>&1729 , <\/span>&(x + y) , <\/span>&std::string(“meow”) , and <\/span>&x++ are all invalid.\u00a0 Why does this work?&nbs\np; The address-of operator requires that its “operand shall be an lvalue” (C++03 5.3.1\/2).\u00a0 Why does it require that?\u00a0 Taking the address of a persistent object is fine, but taking the address of a temporary would be extremely dangerous, because temporaries evaporate quickly.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

The preceding examples ignore operator overloading, which is convenient syntax for a function call.\u00a0 “A function call is an lvalue if and only if the result type is a reference.” (C++03 5.2.2\/10)\u00a0 Therefore, given <\/span>vector<int> v(10, 1729); , <\/span>v[0] is an lvalue because <\/span>operator[]() returns <\/span>int& (and <\/span>&v[0] is valid and useful), while given <\/span>string s(“foo”); and <\/span>string t(“bar”); , <\/span>s + t is an rvalue because <\/span>operator+() returns <\/span>string (and <\/span>&(s + t) is invalid).<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Both lvalues and rvalues can be either modifiable (non-<\/span>const) or non-modifiable (<\/span>const).\u00a0 Here are examples:<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

string one(“cute”);<\/span><\/p>\n

 <\/p>\n

const string two(“fluffy”);<\/span><\/p>\n

 <\/p>\n

string three() { return “kittens”; }<\/span><\/p>\n

 <\/p>\n

const string four() { return “are an essential part of a healthy diet”; }<\/span><\/p>\n

 <\/p>\n

\n

\u00a0<\/span><\/p>\n

 <\/p>\n

one;\u00a0\u00a0\u00a0\u00a0 \/\/ modifiable lvalue<\/span><\/p>\n

 <\/p>\n

two;\u00a0\u00a0\u00a0\u00a0 \/\/ const lvalue<\/span><\/p>\n

 <\/p>\n

three(); \/\/ modifiable rvalue<\/span><\/p>\n

 <\/p>\n

four();\u00a0 \/\/ const rvalue<\/span><\/p>\n

 <\/p>\n

\u00a0<\/span><\/p>\n

Type& binds to modifiable lvalues (and can be used to observe and mutate them).\u00a0 It can’t bind to <\/span>const lvalues, as that would violate <\/span>const correctness.\u00a0 It can’t bind to modifiable rvalues, as that would be extremely dangerous.\u00a0 Accidentally modifying temporaries, only to have the temporaries evaporate along with your modifications, would lead to subtle and obnoxious bugs, so C++ rightly prohibits this.\u00a0 (I should mention that VC has an evil extension that allows this, but if you compile with \/W4 , it warns when the evil extension is activated.\u00a0 Usually.)\u00a0 And it can’t bind to <\/span>const rvalues, as that would be doubly bad.\u00a0 (Careful readers should note that I’m not talking about template argument deduction here.)<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

const Type& binds to everything: modifiable lvalues, <\/span>const lvalues, modifiable rvalues, and <\/span>const rvalues (and can be used to observe them).<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

A reference is a name, so a reference bound to an rvalue is itself an lvalue (yes, L).\u00a0 (As only a <\/span>const reference can be bound to an rvalue, it will be a <\/span>const lvalue.)\u00a0 This is confusing, and will be an extremely big deal later, so I’ll explain further.\u00a0 Given the function <\/span>void observe(const string& str) , inside <\/span>observe()‘s implementation, <\/span>str is a <\/span>const lvalue, and its address can be taken and used before <\/span>observe() returns.\u00a0 This is true even though <\/span>observe() can be called with rvalues, such as <\/span>three() or <\/span>four() above.\u00a0 <\/span>observe(“purr”) can also be called, which constructs a temporary <\/span>string and binds <\/span>str to that temporary.\u00a0 The return values of <\/span>three() and <\/span>four() don’t have names, so they’re rvalues, but within <\/span>observe(), <\/span>str is a name, so it’s an lvalue.\u00a0 As I said above, “lvalueness versus rvalueness is a property of expressions, not of objects”.\u00a0 Of course, because <\/span>str can be bound to a temporary which will evaporate, its address shouldn’t be stored anywhere where it could be used after <\/span>observe() returns.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Have you ever bound an rvalue to a <\/span>const reference and then taken its address?\u00a0 Yes, you have!\u00a0 This is what happens when you write a copy assignment operator, <\/span>Foo& operator=(const Foo& other) , with a self-assignment check, <\/span>if (this != &other) { copy stuff; } return *this; , and you copy assign from a temporary, like <\/span>Foo make_foo(); Foo f; f = make_foo(); .<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

At this point, you might ask, “So what’s the difference between modifiable rvalues and <\/span>const rvalues?\u00a0 I can’t bind <\/span>Type& to modifiable rvalues, and I can’t assign things (etc.) to modifiable rvalues, so can I really modify them?”\u00a0 This is a very good question!\u00a0 In C++98\/03, the answer is that there’s a slight difference: non-<\/span>const member functions can be called on modifiable rvalues.\u00a0 C++ doesn’t want you to accidentally modify temporaries, but directly calling a non-<\/span>const member function on a modifiable rvalue is explicit, so it’s allowed.\u00a0 In C++0x, the answer changes dramatically, making move semantics possible.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Congratulations!\u00a0 Now you have what I call “lvalue\/rvalue vision”, the ability to look at an expression and determine whether it’s an lvalue or an rvalue.\u00a0 Combined with your “<\/span>const vision”, you can precisely reason that given <\/span>void mutate(string& ref) and the definitions above, <\/span>mutate(one) is valid, while <\/span>mutate(two), <\/span>mutate(three()), <\/span>mutate(four()), and <\/span>mutate(“purr”) are invalid, and all of <\/span>observe(one), <\/span>observe(two), <\/span>observe(three()), <\/span>observe(four()), and <\/span>observe(“purr”) are valid.\u00a0 If you’re a C++98\/03 programmer, you already knew which of these calls were valid and which were invalid; your “gut feeling”, if not your compiler, would have told you that <\/span>mutate(three()) was bogus.\u00a0 Your new lvalue\/rvalue vision tells you precisely why (<\/span>three() is an rvalue, and modifiable references can’t be bound to rvalues).\u00a0 Is that useful?\u00a0 To language lawyers, yes, but not really to normal programmers.\u00a0 After all, you’ve gotten this far without knowing all of this stuff about lvalues and rvalues.\u00a0 But here’s the catch: compared to C++98\/03, C++0x has vastly more powerful lvalue\/rvalue vision (in particular, the ability to look at an expression, determine whether it’s a modifiable\/<\/span>const lvalue\/rvalue, and do something about it).\u00a0 In order to use C++0x effectively, you need lvalue\/rvalue vision too.\u00a0 And now you have it, so we can proceed!<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

the copying problem<\/span><\/b><\/p>\n

\u00a0<\/span><\/p>\n

C++98\/03 combines insanely powerful abstraction with insanely efficient execution, but it has a problem: it’s overly fond of copying.\u00a0 Things with value semantics behave like <\/span>ints, so copying a thing doesn’t modify the source, and the resulting copies are independent.\u00a0 Value semantics are great, except that they tend to lead to unnecessary copies of heavy objects like <\/span>strings, <\/span>vectors, and so forth.\u00a0 (“Heavy” means “expensive to copy”; a million-element <\/span>vector is heavy.)\u00a0 The Return Value Optimization (RVO) and Named Return Value Optimization (NRVO), where copy constructors are elided in certain situations, help to alleviate this problem, but they don’t remove all unnecessary copies.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

The most unnecessary<\/i> copies are those where the source is about to be destroyed.\u00a0 Would you photocopy a sheet of paper and then immediately throw away the original, assuming that the original and the photocopy are identical?\u00a0 That would be wasteful; you should keep the original and not bother with the photocopy.\u00a0 Here’s what I call “the killer example”, derived from one of the Standardization Committee’s examples (in N1377).\u00a0 Suppose that you have a bunch of <\/span>strings, like this:<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

string s0(“my mother told me that”);<\/span><\/p>\n

 <\/p>\n

string s1(“cute”);<\/span><\/p>\n

 <\/p>\n

string s2(“fluffy”);<\/span><\/p>\n

 <\/p>\n

string s3(“kittens”);<\/span><\/p>\n

 <\/p>\n

string s4(“are an essential part of a healthy diet”);<\/span><\/p>\n

 <\/p>\n

\u00a0<\/span><\/p>\n

And that you concatenate them like this:<\/span><\/p>\n

\u00a0<\/span><\/p>\n

string dest = s0 + ” ” + s1 + ” ” + s2 + ” ” + s3 + ” ” + s4;<\/span><\/p>\n

 <\/p>\n

\u00a0<\/span><\/p>\n

How efficient is this?\u00a0 (We’re not worrying about this specific example, which executes in microseconds; we’re worrying about its generalization, which occurs throughout the entire language.)<\/span><\/p>\n

\u00a0<\/span><\/p>\n

Each call to <\/span>operator+() returns a temporary <\/span>string.\u00a0 There are 8 calls to <\/span>operator+() , so there are 8 temporary <\/span>strings.\u00a0 Each one, upon its construction, performs a dynamic memory allocation and copies all of the characters that have been concatenated so far, and later, upon its destruction, performs a dynamic memory deallocation.\u00a0 (If you’ve heard of the Small String Optimization, which VC performs in order to avoid dynamic memory allocations and deallocations for short <\/span>strings, it’s defeated here by my carefully chosen and sufficiently long <\/span>s0 , and even if it applied, it couldn’t avoid the copying.\u00a0 If you’ve heard of the Copy-On-Write “optimization”, forget about it – it doesn’t apply here, and it’s a pessimization under multithreading, so Standard Library implementations don’t do it anymore.)<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

In fact, because every concatenation copies all of the characters that have been concatenated so far, this has quadratic complexity in the number of concatenations.\u00a0 Yuck!\u00a0 This is extraordinarily wasteful, which is especially embarrassing for C++.\u00a0 Why is this happening, and what can we do about it?<\/span><\/p>\n

\u00a0<\/span><\/p>\n

The problem is that <\/span>operator+() , which takes two <\/span>const string& or one <\/span>const string& and one <\/span>const char * (there are other overloads, which we aren’t using here), can’t tell whether it’s being fed lvalues versus rvalues, so it always has to create and return a new temporary <\/span>string .\u00a0 Why do lvalues versus rvalues matter?<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

When evaluating <\/span>s0 + ” “ , it’s absolutely necessary to create a new temporary <\/span>string .\u00a0 <\/span>s0 is an lvalue, naming a persistent object, so we can’t modify it.\u00a0 (Someone would notice!)\u00a0 But when evaluating <\/span>(s0 + ” “) + s1 , we could simply append <\/span>s1‘s contents onto our first temporary <\/span>string, instead of creating a second temporary and throwing the first temporary away.\u00a0 This is the key insight behind move semantics<\/b>: because <\/span>s0 + ” “ is an rvalue, an expression referring to a temporary object, no one else in the entire program can observe that temporary object.\u00a0 If we could detect that expression as being a modifiable rvalue, we could then proceed to modify the temporary object arbitrarily, without anyone else noticing.\u00a0 <\/span>operator+() isn’t “supposed to” modify its arguments, but if they’re modifiable rvalues, who cares?\u00a0 In this manner, each call to <\/span>operator+() can append characters onto a single temporary <\/span>string .\u00a0 This completely eliminates the unnecessary dynamic memory management and unnecessary copying, leaving us with linear complexity.\u00a0 Yay!<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

Technically speaking, in C++0x, each call to <\/span>operator+() still returns a separate temporary <\/span>string .\u00a0 However, the second temporary <\/span>string (from evaluating <\/span>(s0 + ” “) + s1 ) is constructed by stealing the memory owned by the first temporary <\/span>string (from evaluating <\/span>s0 + ” “ ) and then appending <\/span>s1‘s contents onto that memory (which may trigger an ordinary geometric reallocation).\u00a0 “Stealing” consists of pointer twiddling: the second temporary copies and then nulls out the first temporary’s internal pointer.\u00a0 When the first temporary is eventually destroyed (“at the semicolon”), its pointer is null, so its destructor does nothing.<\/span><\/span><\/p>\n

\u00a0<\/span><\/p>\n

In general, being able to detect modifiable rvalues allows you to engage in “resource pilfering”.\u00a0 If the objects referred to by modifiable rvalues own any resources (such as memory), you can steal their resources instead of copying them, since they’re going to evaporate anyways.\u00a0 Constructing from or assigning from modifiable rvalues by taking what they own is generically referred to as “moving”, and moveable objects have “move semantics”.<\/span><\/p>\n

\u00a0<\/span><\/p>\n

This is extremely useful in many places, such as <\/span>vector<\/span> reallocation.\u00a0 When a <\/span>vector<\/span> needs more capacity (e.g. during <\/span>push_back()<\/span>) and undergoes reallocation, it needs to copy elements from the old buffer into the new one. If the objects stored in the vector are expensive to copy (e.g. they could be vectors<\/span>\u00a0<\/span>themselves), then this reallocation could be costly. This cost can be greatly reduced in many cases by\u00a0moving<\/em> the old elements into the new buffer rather than copying them. std::vector carries out this operation so long as the move construction of the elements is guaranteed to not throw an exception, as otherwise this could result in lost data.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Part 1 of this series covered lambdas, auto, and static_assert. \u00a0 Today, I’m going to talk about rvalue references, which enable two different things: move semantics and perfect forwarding.\u00a0 This post will be long, because I’m going to explain how rvalue references work in great detail.\u00a0 They’re initially very confusing because they distinguish lvalues from […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4643","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"

Part 1 of this series covered lambdas, auto, and static_assert. \u00a0 Today, I’m going to talk about rvalue references, which enable two different things: move semantics and perfect forwarding.\u00a0 This post will be long, because I’m going to explain how rvalue references work in great detail.\u00a0 They’re initially very confusing because they distinguish lvalues from […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4643","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4643"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4643\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4643"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4643"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4643"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}