Comment by dragontamer | Hacker News Reader

Comment by dragontamer | Hacker News Reader

> (Other not-yet-standard proposals to go further in this direction include ones with names like “relocatable” and “destructive move,” but those aren’t standard yet so it’s premature to talk about them.)

Herb Sutter seems to be burying the lede here. My read on Herb Sutter's post is that the current typical methodology (as represented by the IndirectInt example), is buggy as per the current specification.

What we all want is "destructive move". A lot of us believe that C++ move is "destructive move", but it is not. C++ move is this slightly different, simpler move, that isn't in fact the destructive move that we all want.

---------

As such, Herb Sutter seems to be pushing for a "True Destructive Move" to be included into the C++ specification. Since std::move is CLOSE to the behavior of true-destructive move, we might as well use it if we're writing code today. But the C++ standard should be fixed to include the concept of a real destructive move.

-----

At least, that's my read on things. Anyone else have thoughts? In essence, "C++ Move is simple, perhaps too simple and it doesn't really get the job done".

As the specification is currently written, a "moved-from" C++ object is NOT in any special state, like it is in some other popular languages. Programmers seem to expect a special state however (see IndirectInt).

It's going to be amazing when they add a true "destructive move" and everyone has to learn about the different kinds of moves and when to use which one.

> a "moved-from" C++ object is NOT in any special state, like it is in some other popular languages.

In practice it is; it's in a special state of "satisfies class invariants but otherwise undefined". From the developer's point of view this is very little different from the destructive-move "you can't touch this anymore" state.

> It's going to be amazing when they add a true "destructive move" and everyone has to learn about the different kinds of moves and when to use which one.

No different than when they added move the first time in C++11 and everybody had to learn the difference between copy and move. No different than Rust programmers learning the difference between Rust's move and C++'s move.

Stuff changes over time. In this case, I think it is warranted. The C++11 move is useful in many cases, but not useful enough for how many programmers use unique_ptr<> stuff. Adding that little bit of extra state for the compiler to track might be helpful.

> In practice it is;

That's the mismatch between C++ Programmers and C++ Language. In effect, C++ Programmers want destructive moves and are currently coding their move statements AS IF they were destructive moves.

Herb Sutter is careful to choose the auto_ptr example. Because he's basically saying that unique_ptr is making the same mistake auto_ptr made years ago... the move semantics are subtly different and need to be changed and/or updated.

> No different than when they added move the first time in C++11 and everybody had to learn the difference between copy and move.

Yes, it's not the first time the cognitive load of C++ has increased.

> No different than Rust programmers learning the difference between Rust's move and C++'s move.

Learning concepts in a new language doesn't increase cognitive load in the same way. In C++ you will have to decide which kind of move to use in any given situation, and deal with code using multiple kinds of moves. Learning Rust doesn't create such issues.

> Adding that little bit of extra state for the compiler to track might be helpful.

It'll be interesting to see how that goes. In Rust the compiler ensures safe code can't access a moved-out-of object, but that depends on Rust's strong aliasing guarantees. In C++ I guess accessing a moved-out-of object will have to be a new kind of undefined behavior, creating new classes of bugs and requiring new sanitizers and approximate static checkers to be implemented.

Happily the undefined behavior plan for C++ seems to be, in addition to putting all the UB definitions in one place, requiring all new proposals justify why something should be UB or UD.

E.g. no more "it requires work to say what happens" UB cop outs - if something can be defined it should be.

In this case I'd say that a value cannot be used after it is destructively moved. There is no reason for that to be UB, when the language can just refuse to compile it.

In general the compiler will not be able to prove that the value is not used again, because of possible aliasing. E.g. if you called a method on the object, then the compiler would need to be able to prove that 'this' hasn't been stashed away somewhere so it can be used again (without otherwise triggering undefined behavior) after the object has been moved out of.

I.e. to have the compiler prove absence of use-after-move requires the same sort of lifetime analysis it would need to prove absence of use-after-free, and that is simply not realistic for C++.

Use after free (through references) is a standard problem in C++ through anything. But you can say post-move a value is dead, and use of existing references would be UB (sigh, but that isn't new).

But to address your point: I'm a muppet and didn't think about conditional move in a loop.

I had been thinking that you require that any conditional block has to end with a moved value int he same state - e.g.

if (a) {move(x)} else {}

The compiler would say both blocks must end with x being dead, so the else block would be required to call x.~X();

But yeah, that fails completely if you have

for (...i...) { if (i) move(x) }

because my clever rule means that x would have to die at the end of the first loop.

But the general problem I have with std::move currently is that there's no guaranteed death - the fact that post std::move a destructor will still run, or the object can just continue to be used in general means that your code has to be made defensive against already being logically dead - even if just the destructor.

Rust takes a conservative approach here --- you can't use x if it might have been moved along some control-flow path leading up to the current point. C++ could do that too.

> Use after free (through references) is a standard problem in C++ through anything. But you can say post-move a value is dead, and use of existing references would be UB (sigh, but that isn't new).

OK, arguably aliased-use-after-move could be treated as an existing form of UB. Sanitizers and static checkers would still need to be updated, however.

Destructive move would be incompatible with c++ as it works today. If you construct an object it’s valid. Since move doesn’t do delete() (how could it?) it leaves behind a block of memory that the program considers an X and so must be valid.

The compiler can just say "this value is dead, you can't use it".

That's what rust does - rust isn't literally freeing/clearing memory when a struct is moved.

Rust can do this for an arbitrary element of a dynamically allocated array?

Rust can only do that in unsafe blocks.

The C++ version would need the existing (unchangeable) move semantics.

No. You can't move an element out of an array in Rust.

What Ollie said is true for local variables, and collections generally support some kind of "move element(s) out of the collection" API (e.g. Vec::pop(), T::into_iter()).

So rust can do it in a subset of cases, such that it can make a stronger assertion; C++ can do it in the general case, and is therefore unable to make the stronger assertion.

Neither is correct vs the other, rather they reflect different choice points in the language possibility space.

You can do a C++ style "swap object with a placeholder" move in Rust, easily, with std::mem::replace(). There's no advantage for C++ here.

So, what do you propose std::move<int> should do?

Initializing the ‘source’ int to zero seems the only reasonable option, but it would hurt performance.

Also, what about std::move<T> in general? If T has a destructor, should that call it on the original? Currently, deciding whether that (or doing its equivalent) is a good idea is up to the implementer of std::move<T>. I don’t see how the compiler could make that decision without sacrificing performance in some cases.

I think that, if you want the compiler to enforce destruction of moved-from values, you also should want the compiler to zero out (or equivalent) all destructed values.

std::move has been part of the language for 9 years. It is no longer reasonable to change std::move.

To satisfy the programmer, there probably should be a std::dmove(x), which would be a compiler-enforced notation that would make use of x illegal after the use of std::dmove.

std::dmove(x) would be implemented as std::move, followed by a destructor, and then the compiler removes variable x from the scope. Pointers and references to that variable will have undefined behavior if they are used (compiler may find it reasonable to recycle x's memory location to another variable)

------

std::move<int> remains the same. There's no performance benefit, or even code-logic benefit, to zeroing out integers. For example, an integer may be a denominator, dividand, modulus, or multiplier. In these cases, "zeroing out" to "x = 1" makes more sense than "x=0".

Having a compiler enforced "zero" of "x=0" is arbitrary and doesn't help anybody. Its better to let the integers remain the same value they used to be.

But the whole point of std::move is to avoid calling, possibly expensive, destructors.

The standard example is

  template<typename T>
  void swap(T& x, T& y)
  {
    T z = std::move(x);
    x = std::move(y);
    y = std::move(z);
  }
  ...
  std::string a[1000];
  ...
  std::swap(&a[2], &a[7])

If std::move copy-constructs and destroys, that last line would do three allocations and three frees (recoverable by a significantly advanced compiler, but who has that?). The way std::move is specced, it can do zero allocations and zero frees.

A good point.

So clearly the way std::move works now is great for that situation. But there's a 2nd situation, with Herb Sutter's IndirectInt, which calls for a different behavior.

>So, what do you propose std::move<int> should do?

Just copy Rust. Trivially copyable types aren't invalidated by moves, and "move" just aliases copy.

Is the intention of std::move<unique_ptr> that the "moved-from" pointer no longer has its destructor run?

What if you move a unique_ptr from a std::vector? You don't know which elements of the vector need to have their destructors run.

I think Rust unconditionally doesn't run the destructor of a moved-from Box, but uses drop flags for "maybe-moved-from" local variables, and doesn't allow maybe-moved-from Vec elements.

My point was on handling the moving of trivially copyable types, like int, not those with side effects like unique_ptr. For trivially copyable types, copy and move are (almost) synonymous, and can be made such in Rust with #[derive(Copy)].

But that difference actually gets to your point here. The only difference between copy and move is that a move allows for the new data to overlap the previous. So if you think about what moving from a vector of unique ptr actually means, it must invalidate the vector or remove the element that was moved from the vector. If you want to get the element from the vector without those effects, you have to create a deep copy.

Basically moving without invalidating or mutating such that the moved-from alias can no longer be accessed is necessary.

You’ve referred to two kinds of move there — memmove (overlapping) vs memcpy (non-overlapping memory) and transfers of ownership. In C++ a move appears to always require moving memory with either (depending on aliasing) or via registers. Is that correct?

In Rust, the only thing that has to happen is a transfer of ownership, which does not always mean moving bytes. This greatly simplifies the whole “rvalue reference parameter” thing, because ownership abstracts over wherever you might want to move to. So if your new owner wants it in part of its new stack frame, the compiler is free to just put it there before calling or simply call a destructor on the parent stack frame’s memory in the child. (I don’t know exactly what it likes to do, but it’s all fine.) New owners like Box need to move memory, and that’s cool too, and the compiler is free to reorder the steps to avoid initialising and moving when “placement new” is better. This is also something I believe the compiler is getting better at slowly. The compiler won’t let you safely write moves out of a vector without mutating or taking ownership of the vector, each with moving bytes — otherwise it has access to something it no longer owns.

The easiest example is `let a = A::new(); let b = a;`, which only needs stack space for one A, and for which line 2 is a noop. Its only effect is in when drop is called, if b is in a smaller scope. Does C++ do this too? I would hope so, but it looks like no.

Edit: turns out neither do it.

- https://rust.godbolt.org/z/xjA9v4 - https://godbolt.org/z/7Wh_AZ

Reply on news.ycombinator.com