News for hackers. Stuff that matters.
Re:You can't Rust that by staticassertion on Saturday March 31, 2018 @02:41PM (#16724508)
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.

Re:You can't Rust that by masklinn on Saturday March 31, 2018 @02:58PM (#16724582)
> 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
Re:You can't Rust that by jeremyjh on Saturday March 31, 2018 @05:07PM (#16725179)
I think he just means the move constructor is not guaranteed to move anything. It is only expected to.
Re:You can't Rust that by snuxoll on Saturday March 31, 2018 @11:12PM (#16726500)
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.

Re:You can't Rust that by Too on Sunday April 01, 2018 @01:58AM (#16726973)
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.
Re:You can't Rust that by jcelerier on Sunday April 01, 2018 @10:14AM (#16728371)
> 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.