this post was submitted on 25 Nov 2023
26 points (96.4% liked)

C++

1773 readers
3 users here now

The center for all discussion and news regarding C++.

Rules

founded 1 year ago
MODERATORS
Nihili0@programming.dev
lysdexic@programming.dev
26
On harmful overuse of std::move - The Old New Thing (devblogs.microsoft.com)
submitted 11 months ago by lysdexic@programming.dev to c/cpp@programming.dev
22 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] porgamrer@programming.dev 10 points 11 months ago (2 children)

To me it's not really excitement so much as "oh god how do i make this ridiculous language do the correct thing".

I'm way more scared of rogue implicit copy constructors. I wonder if cppfront has any plan to fix problems like implicit copy and pessimising move.

[–] crispy_kilt@feddit.de 7 points 11 months ago (2 children)

In Rust, making something copyable is always explicit. I like that a lot.

[–] Specialpatrol@feddit.uk 3 points 11 months ago (1 children)

Cpp should have done ref by default and had & for copy, but here we are.

[–] lysdexic@programming.dev 1 points 11 months ago

Cpp should have done ref by default and had & for copy, but here we are.

That would defeat the goal of making it backwards-compatible with C.

[–] Miaou@jlai.lu 3 points 11 months ago (1 children)

Copy has a very different meaning between the two languages. In rust the equivalent of a c++ copy is a clone() call for anything non trivial

[–] BatmanAoD@programming.dev 3 points 11 months ago (2 children)

...which is also explicit.

[–] wosrediinanatour@mastodon.social 2 points 11 months ago (1 children)

@BatmanAoD @Miaou It is just what you are used to.
In C++ everything is a copy. Sometimes the compiler optimizes it away. clang-tidy may help. Having a clone() is very C-like.

[–] Miaou@jlai.lu 1 points 11 months ago* (last edited 11 months ago)

That's a common idiom but the default behaviour is still implicit copy, which, with VLAs and no smart pointers, makes things arguably worse than in c++

[–] Miaou@jlai.lu 1 points 11 months ago

I thought that was obvious as I mentioned a function call, but yes indeed

[–] lysdexic@programming.dev 3 points 11 months ago* (last edited 11 months ago) (1 children)

To me it’s not really excitement so much as “oh god how do i make this ridiculous language do the correct thing”.

I think this all comes down to having the right mental model.

In this case, I think it helps to know that:

  • returning by value by default implies making a copy,
  • ...but if the output type supports move semantics and the function returns a temporary value (rvalue) then the language is on your side and tries to move it instead of doing a copy.
  • and here's the kicker: now the language goes the extra mile and looks after you to avoid that copy, and if your return value allows the language to apply an optimization then the language is on your side and eliminates any potential copy without you having to do anything special.

The zany behavior is that if you set up your function to push for a move (i.e., force a local variable to be treated as a temporary), the language ceases to be able to apply its optimization.

That's basically it. No real mystery.

[–] BatmanAoD@programming.dev 2 points 11 months ago

The parts that seem likely to cause this confusion (which I shared when I first started using C++11) are:

  • Moves in C++ are always a potentially-destructive operation on a reference, not just a memcopy.
  • Consequently, "moving" a temporary still requires having two separate instances of the type, despite that generally not being what you want, hence RVO.
  • ...but move-semantics are generally presented and understood as an "optimization", and conceptually "take the guts of this value and re-use them as a new value" is both what RVO is doing and what move-semantics are doing.
  • std::move isn't a compiler intrinsic and doesn't force a move operation; it's just a function that returns an r-value reference. So it makes it harder, not easier, for the compiler to "see through" and optimize away, even in the case where "as if" rule should make that legal.