[flagged]
C++ std::move doesn't move anything: A deep dive into Value Categories
21–30 of 220 posts
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#22> So the standard library plays it safe: if your move constructor might throw (because you didn’t mark it noexcept), containers just copy everything instead. That “optimization” you thought you were getting? It’s not happening.
This is a bit of a footgun and clang-tidy has a check for it: performance-noexcept-move-constructor. However, I don't think it's enabled by default!
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#23Maybe std::make_movable would have been a slightly better name, but it's so much simpler to write std::move.
thanks to the incredible advances in terms of developer tooling over the last 50 years (i.e. tab-autocompletion) there should be no difference in writing those two.
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#24Naming things is hard.
I'm convinced naming things is equivalent to choosing the right abstraction, and caching things is creating a correct "view" from given normalized data.
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#25The best way to think about it is that std::move is a cast. https://stackoverflow.com/a/42340735
The article explains this.
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#26I always understood move as moving ownership, so it's not a misnomer. > std::move is like putting a sign on your object “I’m done with this, you can take its stuff.” Which exactly is moving ownership.
Std move doesn’t move ownership. It simply casts into something that could have its ownership taken. Whether or not that actually happens is impossible to identify statically and the value after ownership is consumed is unspecified - sometimes it’s UB to access the value again, sometimes it’s not.
After moving a value, it needs to remain in a "valid but unspecified state".
How do you mean accessing a valid object is UB?
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#27Maybe std::make_movable would have been a slightly better name, but it's so much simpler to write std::move.
Split the difference with std::moveable().
Also signals it doesn't actually move, while remaining just as fast to type.
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#28Maybe std::make_movable would have been a slightly better name, but it's so much simpler to write std::move.
std::rvalue
Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#29Re: C++ std::move doesn't move anything: A deep dive into Value Categories
#30Earlier quoted context omitted.
Std move doesn’t move ownership. It simply casts into something that could have its ownership taken. Whether or not that actually happens is impossible to identify statically and the value after ownership is consumed is unspecified - sometimes it’s UB to access the value again, sometimes it’s not.
After moving a value, it needs to remain in a "valid but unspecified state". How do you mean accessing a valid object is UB?
>After moving a value, it needs to remain in a "valid but unspecified state".
No, it doesn't.
The standard library requires that for its classes, but not the language.
"Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state."[0]
[0] https://timsong-cpp.github.io/cppwp/n4950/lib.types.movedfro...