3 ms·

>C++ has no ability to do so, so it does not provide a thread unsafe version. In which case would you like to enforce a thread unsafe version? >Additionally,

>C++ has no ability to do so, so it does not provide a thread unsafe version. In which case would you like to enforce a thread unsafe version? >Additionally, in C++ there's nothing stopping me from wrapping a unique_ptr around a pointer that's aliased else where. This violates the guarantees of a unique_ptr and forces the user to make sure its invariants are held. In Rust the compiler ensures that your Box (Rust's unique_ptr) can never be owned more than once. True, nothing stops you to do that and it is nice to know it on compile time. But I fail to say how you would do this by accident. If you deliberately want to do this kind of things, then you are asking for trouble and it doesn't matter how awesome your language is, you would find a way to shoot your foot.

steveklabnik 11y ago
> In which case would you like to enforce a thread unsafe version? Any time you don't use shared_ptr in a multithreaded context, you're paying extra for the overhead of atomics. In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If you then later try to use it across threads, the compiler won't let you, until you switch to using Arc.
- pmelendez 11y ago
  > In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If I am following you well, then what you are saying is that you if you are in a single thread application you don't need to use a shared_ptr equivalent. Wouldn't that mean that you are using a garbage collected pointer? (Which should have a greater overhead than a shared pointer) because otherwise you would be using plain old raw pointers (with all its problems).
  - steveklabnik 11y ago
    > you don't need to use a shared_ptr equivalent Well, it's the same thing, but without the atmoics. Rc and Arc only differ in the instructions used to update the count, Rc uses regular increment, Arc uses atomic increment. The code is otherwise the same.
    - chadzawistowski 11y ago
      How confusing! Rust's Arc is "atomic reference counting" whereas Obj-C/Swift's Arc is "automatic reference counting"

steveklabnik 11y ago

> In which case would you like to enforce a thread unsafe version? Any time you don't use shared_ptr in a multithreaded context, you're paying extra for the overhead of atomics. In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If you then later try to use it across threads, the compiler won't let you, until you switch to using Arc.

pmelendez 11y ago
> In Rust, if you need shared ownership, but you're not doing anything with threads, you can remove that overhead. If I am following you well, then what you are saying is that you if you are in a single thread application you don't need to use a shared_ptr equivalent. Wouldn't that mean that you are using a garbage collected pointer? (Which should have a greater overhead than a shared pointer) because otherwise you would be using plain old raw pointers (with all its problems).
- steveklabnik 11y ago
  > you don't need to use a shared_ptr equivalent Well, it's the same thing, but without the atmoics. Rc and Arc only differ in the instructions used to update the count, Rc uses regular increment, Arc uses atomic increment. The code is otherwise the same.
  - chadzawistowski 11y ago
    How confusing! Rust's Arc is "atomic reference counting" whereas Obj-C/Swift's Arc is "automatic reference counting"