4 ms·
Unless someone implements Copy on a type that allocates in Rust (which you shouldn't do; Copy is specifically for types that are cheap to copy), you really won'
by boardwaalk 6y ago
Unless someone implements Copy on a type that allocates in Rust (which you shouldn't do; Copy is specifically for types that are cheap to copy), you really won't get implicit copies, though.
That means in any reasonable code, `let x = y` won't allocate in Rust while `T x = y` could in C++. `f(x)` in Rust won't either for the same reason. And that's on top of how C++ will implicitly take a reference, so even if you know x is a heavy object, you don't know if `f(x)` will be expensive (or if `f(move(x))` would be helpful).
It's just not exactly equivalent. C++ is more implicit and has less baked-in good practices like `Copy` vs `Clone`. The indirection is often shallower (less often I have to inspect a function prototype or type I'm using for specifics), and I find that very useful.
- dthul 6y agoMinor clarification: afaik it's impossible to implement Copy such that it would allocate. Unlike Clone, the Copy trait is only a marker trait which doesn't have methods, so you cannot customize its behavior. It will always be a bitwise stack copy.
- bestouff 6y agoThis is not minor. In Rust "x = y" specifically only copies or moves bytes, no magic involved, no code is run except something like memcpy. - If the type isn't marked Copy, it's a bytes move (which will very probably be optimized out). - If the type is marked Copy (which is possible only if all its subtypes are also marked Copy, which allocating types are not) then it's a bytes-for-bytes copy. As soon as you need something more involved, then you have to implement (or derive for simple types) Clone.
- steveklabnik 6y agoThe real key here is that something that allocates will want to Drop said memory, and you can’t implement both Drop and Copy.