4 ms·

They're talking about move semantics, not actual memory moving around. In c++ you get copy semantics by default, requiring std::mov to get move semantics. In r

They're talking about move semantics, not actual memory moving around. In c++ you get copy semantics by default, requiring std::mov to get move semantics. In rust it is the opposite.

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

They're talking about move semantics, not actual memory moving around. In c++ you get copy semantics by default, requiring std::mov to get move semantics. In rust it is the opposite.

masklinn 9y ago

> 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)

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