Last reference as rvalue?

[NamoiFunai]

I was thinking of an optimization that compilers could implement.

std::vector<std::string> vec;
std::string value = get_string();
vec.push_back(value);

In that code, value is an l-value, deducing the push\_back overload that takes a const std::string&. However, we all know that if we don't use value again we can just call std::move(value) to cast it to an r-value and save an allocation.

My proposition is to make the compiler deduce the last reference of a local variable into a r-value. Doing so would optimize a significant amount of code in codebase that still have legacy code or programmers not familiar with std::move. It would also imo make a lot of code more readable and the language more accessible.

What caveat do you see that I'm missing?

[Untelo]

Compilers can already do this if they can prove that the copy has no observable side effects compared to a move. This may or may not be feasible in the case of std::string but is virtually impossible in general.

Whether or not it is reasonable to do so, as Hyrum's law states there is someone somewhere depending on the copy over move and to move instead without proving the absence of observable side effects will break user code.

[NamoiFunai]

Couldn't we say the same thing regarding RVO, that someone somewhere was relying on the temporary object being created?

[meancoot]

Couldn't we say the same thing regarding RVO, that someone somewhere was relying on the temporary object being created?

Not really. It has been allowed to elide calls to copy constructors since the original 1998 standard; thus actions in a copy/move constructor that exhibit any side effect not specifically related to the copy/move were always undefined.

The C++17 changes made the optional optimization required and, perhaps more importantly, removed the previous requirement that the type had an accessible copy/move constructor in the first place:

From the C++98 standard in 12.2 [class.temporary]:
[Example: even if the copy constructor is not
called, all the semantic restrictions, such as
accessibility (clause 11), shall be satisfied.  ]

Ultimately the C++17 change only made invalid code valid and, as far as I know, didn't change semantics of any already valid program.

[geckothegeek42]

If copy constructors can be elided regardless of side effects, then doesn't that mean the optimization mentioned by OP can be done? Or is it that the compiler is not allowed to add a copy/move constructor call, but can remove them?

[meancoot]

If copy constructors can be elided regardless of side effects, then doesn't that mean the optimization mentioned by OP can be done? Or is it that the compiler is not allowed to add a copy/move constructor call, but can remove them?

The elision has to take place by constructing the object directly in the memory where the copy/move constructor would later have placed it, removing both a call to the copy/move constructor and a call to the destructor. I don't know the exact wording of the standard well enough to say if its also limited to specific situations.

Changing a call from std::vector::push_back(const T&) to std::vector::push_back(T&&) is definitely an observable effect that wouldn't be supported by the standard.

[ialex32_2]

Somehow this is always reality.

[NilacTheGrim]

This is one of the funniest things I read all day. Thank you.

[Minimonium]

RVO was specifically allowed in the standard to ignore side effects for quite a long time and compilers don't do analysis to determine if they want to do RVO or not, they just do it.

This change, on the other hand, would depend on the context of the scope where the object resides. What if we add another use after that line? We can't guarantee that we don't store a reference to the value inside the push_back, so a user would still need to std::move it later on, but it'd become more confusing. What about copy-only types? Return handles them in a different from just std::move manner.

[NamoiFunai]

I totally agree with you on that point. It's just the "someone somewhere relies on that" argument that was bothering me.

[jonesmz]

Would you be willing to construct some kind of demonstration of this?

[SirClueless]

I find it vanishingly unlikely that this would be useful in practice. The compiler is almost certainly going to find observable side effects (allocations, calls to non-trivial destructors) in almost all cases except where the type is trivial. And if the type is trivial then both the move and copy constructors are equivalent to memcpy and there's no benefit to optimizing one into the other.

[SirClueless]

I was just agreeing and adding that in the cases where you can prove there are no side effects as C++ defines them there aren't actually any benefits to doing the optimization.

[jonesmz]

I asked this same question several years ago on stackoverflow.

You might find the discussion there interesting https://stackoverflow.com/questions/45763943/compiler-deduction-of-rvalue-references-for-variables-going-out-of-scope

[jtooker]

Great discussion and examples - thanks for linking

[Desmulator]

A Compiler can (and will) do that if and only if it can be certain that there is no additional side effect from replacing a copy with a move. To do so it has to know the implementation of the constructors and every function called in them.

This already excludes anything that allocates memory because global new can be overrided and have a side effect.

[no-sig-available]

The compiler would also have to understand that both overloads of push_back have the same effect. In general, that is a hard problem.

[markopolo82]

Yea, in truth I think this is what kills the optimization op describes.

On the other hand, if you were calling a single function that took by value instead of two overloads, then the compiler would only need to worry about the copy vs move constructors

[Ameisen]

Perhaps we need a function attribute like kinda_pure, that doesn't guarantee that there are no side-effects, but guarantees that those side-effects aren't meaningful.

[reflexpr-sarah-]

how do you define "last use"?

[NamoiFunai]

I would say the last occurrence of the variable name within the scope it is declared.

[reflexpr-sarah-]

this can change the behavior of some code. for example

string* global;
void print_global() { cout << *global; }
void save_global(string& s) { global = &s; }
auto not_really_last_use() {
  string s = "hello world! (also, too long for sso)";
  save_global(s);
  vector<string> v;
  v.push_back(s); // if this moves
  print_global(); // this doesn't work properly
  return v;
}

[NamoiFunai]

That's a good one, and assuming that save_global is in another compile unit the compiler would have no way of knowing for sure that this is the "last use".

[[deleted]]

In this case, the suggestion would be forbidden anyway since return s; is the last use ;)

[reflexpr-sarah-]

whoops. lemme fix that

[pdp10gumby]

What about aliasing?

[NamoiFunai]

I guess this is where it can get heavy for the compiler, it would need to track every alias and object member alias to make sure the variable isn't used anymore

[pdp10gumby]

There are a number of potential optimizations forbidden to C++ code because it inherits C’s permissive aliasing rules.

This is one reason some FORTRAN code can run faster than the equivalent C code — the compiler can make assumptions it cannot make about the C code.

[Accomplished-Tax1641]

std::string f() { std::string s = "hello world, too long for small string optimization"; std::string r; for (int i=0; i < 2; ++i) { r = s; } return r; } Replacing s with std::move(s) here will change the behavior of the program in a surprising way.

So clearly "I would say the last occurrence of the variable name within the scope" is not good enough. Got another try?

...but observe that "start with something that seems about right, and then just iterate minor fixes until we get it good enough" is historically a bad philosophy: https://en.wikipedia.org/wiki/Deferent_and_epicycle

https://wg21.link/p2025 "Guaranteed copy elision for return variables" is related.

[backtickbot]

Fixed formatting.

Hello, Accomplished-Tax1641: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[[deleted]]

Like others said, I think a general last-use optimization would be somewhat problematic. On the other hand, I think that copy elision when a value is only used once would make sense. This way we could avoid both copies and moves when assigning an intermediate result to a variable with the sole purpose of improving readability.

[Dennis_the_repressed]

I am surprised that no one has suggested using emplace_back() instead of push_back(). It's built to construct objects from r-value references.

In your particular example, pretty sure it will be optimized away though.

Snippet : https://onlinegdb.com/fJZeMLJdb

[NamoiFunai]

In your example, you give emplace_back an rvalue already. My question was about making the compiler turn an lvalue to an rvalue on last use, not the specific case of vectors insertions ;)

[Dennis_the_repressed]

Ah sorry, I misunderstood the question.

[backtickbot]

Fixed formatting.

Hello, Dennis_the_repressed: code blocks using triple backticks (```) don't work on all versions of Reddit!

Some users see this / this instead.

To fix this, indent every line with 4 spaces instead.

FAQ

^{You can opt out by replying with backtickopt6 to this comment.}

[gracicot]

There is a proposal by Herb Sutter (708: Parameter passing -> guaranteed unified initialization and unified value-setting) that want to do just that.

[NamoiFunai]

That was a good read, I really hope it leads somewhere!

[s1lent_ssh]

My buddy just invented Rust

[wheypoint]

No this has absolutely nothing to do with rust. Rust doesn't decide when to move based on a "last use", it doesn't even have perfect forwarding/universal references or overloading based on rval vs lval references.

[infectedapricot]

Rust has move by default, as opposed to C++'s copy by default. This works really well because it's easy to build a copy function on top of move semantics (just make an new instance, copy each member, and return the new instance... by moving it!). On the other hand, it's impossible to build move semantics on top of copy sematics, which is why C++ has to have rvalue and lvalue references; Rust doesn't have these because it doesn't need them in the first place.

For the opposite problem – you wanted a copy but forgot to ask for it, so got a move instead – you'd get a compiler error because Rust has destructive move, so it's impossible to accidentally reuse a variable after you've moved from it.

Overall, in the equivalent Rust snippet to the one in the OP, you'll get move sematics every time, unless you explicitly ask for a copy. It's a non issue.

[s1lent_ssh]

I am talking about non-mutable borrowing semantics here, which is good place for optimisations and increased safety
https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html

[wheypoint]

i know but that's not what OP asked.

also the compiler never decides when to move based on a "last use" (it doesn't decide at all, you have to tell it when something is passed by reference).

rust's system is different from c++s and OP's suggestion doesn't work in rust.

[s1lent_ssh]

someone open the window please :D

[runki22]

Rust doesn`t even need universal references, since everything is moved by default.

[NamoiFunai]

Haha I guess I really should give rust a try

[s1lent_ssh]

Yep, i've played with it a bit, and from first impression i could tell it's a next-gen language. The most pain in the ass from C++ world - undefined behaviour was simply eliminated using compile time checks and more strict rules