{"id":109842,"date":"2024-06-03T07:00:00","date_gmt":"2024-06-03T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=109842"},"modified":"2024-06-03T06:56:28","modified_gmt":"2024-06-03T13:56:28","slug":"20240603-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20240603-00\/?p=109842","title":{"rendered":"More on harmful overuse of std::move<\/CODE>"},"content":{"rendered":"

Some time ago, I wrote about harmful overuse of std::move<\/code><\/a>. Jonathan Duncan asked,<\/p>\n

Is there some side-effect or other reason I can’t see return std::move(name); case isn’t possible to elide<\/a>? Or is this just a case of the standards missing an opportunity and compilers being bound to obey the standards?<\/p><\/blockquote>\n

In the statement return std::move(name);<\/code>, what the compiler sees is return f(...);<\/code> where f(...)<\/code> is some mysterious function call that returns an rvalue. For all it knows, you could have written return object.optional_name().value();<\/code>, which is also a mysterious function call that returns an rvalue. There is nothing in the expression std::move(name)<\/code> that says, “Trust me, this rvalue that I return is an rvalue of a local variable from this very function!”<\/p>\n

Now, you might say, “Sure, the compiler doesn’t know that, but what if we made it know that?” Make the function std::move<\/code> a magic function, one of the special cases where the core language is in cahoots with the standard library.<\/p>\n

This sort of in-cahoots-ness is not unheard of. For example, the compiler has special understanding of std::launder<\/code>, so that it won’t value-propagate memory values across it, and the compiler has special understanding of memory barriers, so that it won’t optimize loads and stores across them.<\/p>\n

So why not add std::move<\/code> to the list of functions that the compiler has special understanding of? Technically, this is already permitted by the standard, because the standard requires that any specialization of a templated standard library function “meets the standard library requirements for the original template,” so you can’t write a specialization of std::move<\/code> that, say, returns a copy<\/i> of the object. However, I think it’s still legal for the specialization to send angry email to your boss\u00b9 before returning the rvalue reference.<\/p>\n

Okay, so we add a new clause to the standard that says that specializations of std::move<\/code> are disallowed.<\/p>\n

This does leave in the lurch alternate implementations of std::move<\/code>. For example, the Windows Implementation Library (WIL) has its own implementation of std::move<\/code> called wistd::move<\/code>. It does this because some of the components that use WIL operate under a constraint that C++ exceptions are disallowed, which means that they cannot #include <memory><\/code>. But it would also mean that wistd::move<\/code> is no longer a drop-in replacement for std::move<\/code>: The compiler would recognize std::move<\/code> as special, but not wistd::move<\/code>.<\/p>\n

Okay, so we tell those people, “Oh, stop being such a stick in the mud. Come on in, the water’s fine! Use std::move<\/code>!”<\/p>\n

If we operated na\u00efvely, we would say, “Sure you can return the std::move<\/code> of a local variable, and we’ll reuse the return value slot.” But that would be wrong, because that would be move-constructing an object from another object that resides at the same address, which is not something that happens in normal C++, and I suspect that a lot of move constructors don’t handle that case. (Not that I expect them to.)<\/p>\n

So the C++ language would have to disavow the move constructor at all. It could say that if the return<\/code> statement takes the form return std::move(name)<\/code> where name<\/code> is the name of a local variable eligible for NRVO, then the std::move<\/code> may be elided.<\/p>\n

And maybe to accommodate those people who are afraid of exception-infested waters, you could expand the rule to say that if the compiler can determine that the returned value is an rvalue to a local variable that is eligible for NRVO, then it can be rewritten as returning that local variable via NRVO (while still preserving any other observable behaviors of the relevant expression).<\/p>\n

I mean, you could<\/i> do this. Maybe you can even write up a proposal and see what the language committee thinks.<\/p>\n

Oh wait, somebody already wrote that proposal! Stop Forcing std::move<\/code> to Pessimize<\/a>, which was presented to the C++ standard committee in November 2023, and the response was “Weak consensus, needs more work<\/a>“.<\/p>\n

Bonus viewing<\/b>: CppCon 2018: Arthur O’Dwyer “Return Value Optimization: Harder Than It Looks<\/a>“.<\/p>\n

\u00b9 More practical examples would be “doing performance logging” or “doing debug logging” rather than “sending angry email to your boss”.<\/p>\n","protected":false},"excerpt":{"rendered":"

Could we expand copy elision to cover the harmful cases?<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-109842","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Could we expand copy elision to cover the harmful cases?<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109842","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=109842"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/109842\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=109842"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=109842"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=109842"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}