4 ms·
So generally you have to copy arrays, you can't meaningfully move them (you can move each element of course). For vectors with heap allocated backing store of c
by gpderetta 4y ago
So generally you have to copy arrays, you can't meaningfully move them (you can move each element of course). For vectors with heap allocated backing store of course you only need to copy the pointer to heap.
For this particular example it seems that the rust compiler is failing to implement the equivalent of NRVO though, so it is not necessarily related to mives. Do rust semantics allow NRVO? There are no copy/move constructors with side effects, so the only issue is object identity.
Disclaimer: I'm just a c++ programmer, I know very little about rust.
- lalaithion 4y agoNRVO is a completely transparent optimization that Rust tries to do whenever possible. I don’t know what sort of case you can get into with object identity but I suspect it’s obviated by making moved-out-of values untouchable at compile time.
- gpderetta 4y agoC++ example: using array = std::array<int, 10>; array make(array* y) { array result = {...}; assert(&result != y); return result; } array x = make(&x); Normally in C++ distinct objects (result and x) have distinct addresses, so the assert would be guaranteed not to fire. But NRVO is explicitly allowed in the standard to violate this guarantee, so result can overlap with x. In rust you likely cannot get the address of the not-yet-constructed x, but it might be possible to construct equivalent examples.