29
On harmful overuse of std::move - The Old New Thing
(devblogs.microsoft.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 25 Nov 2023
29 points (96.8% liked)
C++
1732 readers
1 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 1 year ago
MODERATORS
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.
In Rust, making something copyable is always explicit. I like that a lot.
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
...which is also explicit.
@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.
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++
I thought that was obvious as I mentioned a function call, but yes indeed
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.
I think this all comes down to having the right mental model.
In this case, I think it helps to know that:
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.
The parts that seem likely to cause this confusion (which I shared when I first started using C++11) are:
std::moveisn'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.