> In c++ you get copy semantics by default, requiring std::mov to get move semantics.
And even then:
1. std::move only creates an rvalue reference, it doesn't necessarily move anything (not only does that depend on the presence of a move ctor & the receiver's arguments, there's still no requirement that anything actually moves)
2. a move in the C++ sense "empties" the object, the object is still there and accessible in "some valid but otherwise indeterminate state", objects can even fully specify the exact state they're in when moved-from (unique_ptr does)
Re:You can't Rust that
by bergesenha on Saturday March 31, 2018 @04:28PM
(#16725018)
1. I thought the cast to an rvalue reference would make overloads taking rvalue references be chosen during overload resolution. Since this is deterministic I thought whether something is moved or not would be quite guaranteed
I think he just means the move constructor is not guaranteed to move anything. It is only expected to.
The rule of three/five is probably the most tedious thing to deal with in modern C++. Assuming all your member variables are C++ types it's not TERRIBLE, you should be able to handle everything in the initialization list (using std::move for the move constructor) - but it's still easy to forget to initialize a member.
This is one area where Rust really makes life much easier.
Use rule of zero as far as possible. All the tedious stuff that comes with rule of five should be isolated to very few components in your code.
> 1. I thought the cast to an rvalue reference would make overloads taking rvalue references be chosen during overload resolution. Since this is deterministic I thought whether something is moved or not would be quite guaranteed
well, take for instance this function :
my_struct eat_pointer(std::unique_ptr<int>&& x) {
if(x && *x > 0)
return my_struct{std::move(x)};
return my_struct{};
}
auto my_pointer = std::make_unique<int>(-456);
auto res = eat_pointer(std::move(my_pointer));
// at this point my_pointer hasn't moved a bit
sure, this code sucks, but that's always a possibility
Re:You can't Rust that
by bergesenha on Sunday April 01, 2018 @07:12PM
(#16731077)
Thanks for the example, I understand. I missunderstood the poster above. I've come across quite a few coworkers who believe that move is something that happens on the compilers whim as part of some optimization and incorrectly assumed the same of the post i replied to.
In c++ you get copy semantics by default, requiring std::mov to get move semantics. In rust it is the opposite.