Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

  > 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.


> 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).


  > 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.


How confusing! Rust's Arc is "atomic reference counting" whereas Obj-C/Swift's Arc is "automatic reference counting"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: