Move in C++ without a std:move
andreasfertig.com
Move in C++ without a std:move
1–10 of 75 posts
Re: Move in C++ without a std:move
#2I'd push back slightly on move — at small scale the opposite has been true for me.
Re: Move in C++ without a std:move
#3I'd push back slightly on move — at small scale the opposite has been true for me.
Not sure what you mean, but std::move is one of the greatest tools in C++
Re: Move in C++ without a std:move
#4If the author is reading: both complicated examples are the same.
Re: Move in C++ without a std:move
#5Unfortunately, I don't think there's getting away from just understanding value semantics to get the correct and/or performant behavior.
Re: Move in C++ without a std:move
#6If the author is reading: both complicated examples are the same.
Yeah, the second one is supposed to read `Apple&& Cat(Apple&& val) {
return val;
}` — but the return type's `&&` was omitted by accident.
Re: Move in C++ without a std:move
#7What is that makes NVRO so much more difficult to implement? Why couldn't they mandate that just like RVO?
Do compilers literally just special case a simple return statement of a direct construction or something?
Re: Move in C++ without a std:move
#8Re: Move in C++ without a std:move
#9Earlier quoted context omitted.
Not sure what you mean, but std::move is one of the greatest tools in C++
This is one case where Rust benefited from C++’s experience — move by default with opt-in clone/copy is IMO the better setup.
And the most important idea: destructive moves.
Since C++ doesn't track lifetimes it has to leave the object in a "valid state" after a move and the destructor still runs which has to have a check if it should do something or not.
Re: Move in C++ without a std:move
#10What is that makes NVRO so much more difficult to implement? Why couldn't they mandate that just like RVO? Do compilers literally just special case a simple return statement of a direct construction or something?
The simple cases are simple. However the complex cases get hard.
mytype foo() {
mytype one;
...
if(something) {
mytype two;
...
return two;
}
return one;
}
Is going to be much harder because you don't know are compile time which is returned and so cannot construct the one you return in the correct place. That is just off the top of my head, I'm not a compiler writer, I'm sure they have figured out the simple versions of the above, but you can start to see the complex versions that they can't.