4 ms·
This is wrong. Passing a large struct by value does introduce a memcpy... in the caller: https://godbolt.org/g/26annS https://godbolt.org/g/26annS The same is
by Rusky 8y ago
This is wrong. Passing a large struct by value does introduce a memcpy... in the caller: https://godbolt.org/g/26annS https://godbolt.org/g/26annS
The same is true in Rust, though it's trickier to show on godbolt because the equivalent of `extern` is less accessible in that context.
Rust programs often put those large structs in Boxes when they need to transfer ownership of something large, which is something straight out of "C mode."
- evmar 8y agoHere it is on godbolt (using noinline): https://godbolt.org/g/7bskDc https://godbolt.org/g/7bskDc The point I (poorly) was trying to make here was that passing things by value in Rust is fairly common, for e.g. Rc<T> or Option<T>, while in the C I've seen you basically never pass structs by value. But I guess, continuing the analogy, in C++ you do pass the equivalent of Rc<T> by value.
- yoklov 8y agoIt’s pretty common in both C and C++ to pass things by value, at least for more modern code. Maybe less common than in Rust, but not by that much.
- cwzwarich 8y agoIt's also common in C++ (at least in some coding styles) to pass large structs by const reference, creating the dilemma of when to pass by value and when to pass by reference, which has no perfect general solution.
- noncoml 8y agoYou are absolutely right. The Rust book makes it sound like that passing structs is free, but it’s absolutely not. It’s always bit-wise copy. Relevant Reddit and Stackiverflow discussion with godbolt examples: https://www.reddit.com/r/rust/comments/8ts6b4/is_anyone_else_worried_of_performance_issues_due/ https://www.reddit.com/r/rust/comments/8ts6b4/is_anyone_else... I felt a bit betrayed when I read them..
- steveklabnik 8y agoRVO and NRVO are supposed to happen, as far as I know, which is why I said it in the book. Compiler bugs do happen. But also, from that thread: https://www.reddit.com/r/rust/comments/8ts6b4/is_anyone_else_worried_of_performance_issues_due/e1bt47w/ https://www.reddit.com/r/rust/comments/8ts6b4/is_anyone_else... For example: https://godbolt.org/g/DTMQM5 https://godbolt.org/g/DTMQM5 (or https://godbolt.org/g/LHMgHr https://godbolt.org/g/LHMgHr with C side-by-side) (and yes, I know that char != u8, this is just for demonstration purposes) here, you have mov rdi, rsp call example::hello@PLT not a memcpy. Right? Looks the same as the C version that takes char*.
- cwzwarich 8y ago[stupid comment]
- deleted 8y ago[deleted]
- steveklabnik 8y agoIsn’t that the array initialization?
- noncoml 8y agoI think something else is going on here, because I shouldn't be allowed to call `hello(name)` twice if it was a move, should I? https://godbolt.org/g/qUuETC https://godbolt.org/g/qUuETC
- steveklabnik 8y agoArrays are Copy when T is Copy. u8 is Copy.
- noncoml 8y agoAh.. I see, thanks for correcting me! Obviously I don't know enough Rust to argue about this. So, is something like this(https://godbolt.org/g/1ugxcW https://godbolt.org/g/1ugxcW) a inefficiency of the optimizer that we should hope to see fixed at some point?