4 ms·

> Neither C nor C++ knows, at the language level, the size of an array, unless that size is fixed. Neither does Rust. > The subscript checking variants of C a

> Neither C nor C++ knows, at the language level, the size of an array, unless that size is fixed. Neither does Rust. > The subscript checking variants of C and C++ have to use "fat pointers" which carry along size information. So do Rust's Slices. > The overhead for this is large and nobody uses that. People use std::vector all the time for this purpose in C++. It has about the performance you'd expect, with very little overhead except where you want it in bounds-checking. I don't think there's actually a performance difference here. Rust's default is safer because it requires dropping to unsafe code to do something dangerous, but the same optimizations are available in both.

steveklabnik 10y ago
One thing that I've heard might be a difference, but haven't confirmed yet: Rust's lack of move constructors. So you have a vector, it's full, you push one more. It has to reallocate. How do you copy all of the elements over to the new allocation? In Rust, it's a straight memcpy of T * n bytes. But due to move constructors in C++, IIRC they must be moved one at a time. Again, I haven't actually dug into this; maybe someone more knowledgeable about this can point me in the right direction here?
- sirclueless 10y ago
  Well, for trivially copyable types[1] the reallocation can be a straight memcpy. For the rest, I don't know that having or not having a move constructor is the important distinction; it will be preferred over the copy constructor if it is declared as not throwing exceptions, but either way some constructor of the object must be called if it exists (though it might be inlined and optimized away). I imagine Rust does something similar, copying bytes if the underlying type has the `Copy` trait and calling some actual code if not, but I'm not familiar with the details. [1]: http://en.cppreference.com/w/cpp/concept/TriviallyCopyable http://en.cppreference.com/w/cpp/concept/TriviallyCopyable
  - steveklabnik 10y ago
    Thanks for elaborating on this! > copying bytes if the underlying type has the `Copy` trait and calling some actual code if not, It does not. Moves and copies are both "memcopy these bytes", the only difference is if you can use the previous copy or not. (This is also, of course, subject to the optimizer, which may elide the copy.) > either way some constructor of the object must be called if it exists (though it might be inlined and optimized away). Yeah, this is what I was getting at; this has to happen in C++, but not in Rust. You are right to point out that this only matters for things that aren't trivially copyable.
    - sirclueless 10y ago
      Interesting. How does Rust handle types that want to do interesting things when copied, like bookkeeping or updating internal pointers? Maybe you just can't, which would preclude some kinds of intrusive data structures, or owning non-copyable mutexes for example. Does `drop()` get called on objects that have been copied from?
      - steveklabnik 10y ago
        You pretty much just can't; that's what Manish was referencing above about this kind of thing being awkward. It would be cool to have those things, but it also means that there's less "magic" stuff going on, which is nice. And it makes the semantics of stuff like this a lot simpler. > Does `drop()` get called on objects that have been copied from? Nope. In fact, Copy types can't have a Drop at all, but types that move don't have their Drop impl called when they move.
        sirclueless 10y ago
        Thanks for all the responses, I'm learning a lot. This explains to me why iterators and other references to the internals of a data type have to take ownership of the whole data type, which is something I ran into several times during my (brief) explorations with Rust.
- Manishearth 10y ago
  This is correct. I suppose if you could get folks to mark all memcpy move ctors explicitly with a macro instead of relying on the default you could specialize std::vector's move with sfinae. Bit hacky. It already specializes for pod types though. Lack of move and copy ctors in rust greatly simplifies things like this, and makes it very explicit when code is running, but the trade-off is that intrusive data structures are hard to do on the stack in rust.
- rustmemcpy 10y ago
  How would a self-referential object work in Rust in that case? The move or copy constructor could not be a simple memcpy. The self-reference would point to the old object. See this for an example: http://ideone.com/sEFtbN http://ideone.com/sEFtbN
  - sirclueless 10y ago
    See steveklabnik's detailed answers elsewhere in this thread, but the short answer is that you can't write this data type in Rust.
  - Manishearth 10y ago
    https://github.com/Kimundi/owning-ref-rs https://github.com/Kimundi/owning-ref-rs exists, but basically you just don't do intrusive datastructures on the stack in rust. (Intrusive datastructures on the heap are doable with some tricks.) They're not very essential so it works out.

steveklabnik 10y ago

One thing that I've heard might be a difference, but haven't confirmed yet: Rust's lack of move constructors. So you have a vector, it's full, you push one more. It has to reallocate. How do you copy all of the elements over to the new allocation? In Rust, it's a straight memcpy of T * n bytes. But due to move constructors in C++, IIRC they must be moved one at a time. Again, I haven't actually dug into this; maybe someone more knowledgeable about this can point me in the right direction here?

sirclueless 10y ago
Well, for trivially copyable types[1] the reallocation can be a straight memcpy. For the rest, I don't know that having or not having a move constructor is the important distinction; it will be preferred over the copy constructor if it is declared as not throwing exceptions, but either way some constructor of the object must be called if it exists (though it might be inlined and optimized away). I imagine Rust does something similar, copying bytes if the underlying type has the `Copy` trait and calling some actual code if not, but I'm not familiar with the details. [1]: http://en.cppreference.com/w/cpp/concept/TriviallyCopyable http://en.cppreference.com/w/cpp/concept/TriviallyCopyable
- steveklabnik 10y ago
  Thanks for elaborating on this! > copying bytes if the underlying type has the `Copy` trait and calling some actual code if not, It does not. Moves and copies are both "memcopy these bytes", the only difference is if you can use the previous copy or not. (This is also, of course, subject to the optimizer, which may elide the copy.) > either way some constructor of the object must be called if it exists (though it might be inlined and optimized away). Yeah, this is what I was getting at; this has to happen in C++, but not in Rust. You are right to point out that this only matters for things that aren't trivially copyable.
  - sirclueless 10y ago
    Interesting. How does Rust handle types that want to do interesting things when copied, like bookkeeping or updating internal pointers? Maybe you just can't, which would preclude some kinds of intrusive data structures, or owning non-copyable mutexes for example. Does `drop()` get called on objects that have been copied from?
    - steveklabnik 10y ago
      You pretty much just can't; that's what Manish was referencing above about this kind of thing being awkward. It would be cool to have those things, but it also means that there's less "magic" stuff going on, which is nice. And it makes the semantics of stuff like this a lot simpler. > Does `drop()` get called on objects that have been copied from? Nope. In fact, Copy types can't have a Drop at all, but types that move don't have their Drop impl called when they move.
      - sirclueless 10y ago
        Thanks for all the responses, I'm learning a lot. This explains to me why iterators and other references to the internals of a data type have to take ownership of the whole data type, which is something I ran into several times during my (brief) explorations with Rust.
Manishearth 10y ago
This is correct. I suppose if you could get folks to mark all memcpy move ctors explicitly with a macro instead of relying on the default you could specialize std::vector's move with sfinae. Bit hacky. It already specializes for pod types though. Lack of move and copy ctors in rust greatly simplifies things like this, and makes it very explicit when code is running, but the trade-off is that intrusive data structures are hard to do on the stack in rust.
rustmemcpy 10y ago
How would a self-referential object work in Rust in that case? The move or copy constructor could not be a simple memcpy. The self-reference would point to the old object. See this for an example: http://ideone.com/sEFtbN http://ideone.com/sEFtbN
- sirclueless 10y ago
  See steveklabnik's detailed answers elsewhere in this thread, but the short answer is that you can't write this data type in Rust.
- Manishearth 10y ago
  https://github.com/Kimundi/owning-ref-rs https://github.com/Kimundi/owning-ref-rs exists, but basically you just don't do intrusive datastructures on the stack in rust. (Intrusive datastructures on the heap are doable with some tricks.) They're not very essential so it works out.