5 ms·

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 t

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

jeremyjh 9y ago
I think he just means the move constructor is not guaranteed to move anything. It is only expected to.
- snuxoll 8y ago
  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.
  - Too 8y ago
    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.
jcelerier 8y ago
> 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
- bergesenha 8y ago
  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.

jeremyjh 9y ago

I think he just means the move constructor is not guaranteed to move anything. It is only expected to.

snuxoll 8y ago
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.
- Too 8y ago
  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.

jcelerier 8y ago

> 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

bergesenha 8y ago
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.