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

> I'm just wondering if there are other magic pointer types or type system features that also protect memory.

Oh, I see. In that case yes, there are also explicit lifetimes, which allow you to squeeze out more expressiveness to cover most of C++'s use cases for pointers/references: http://static.rust-lang.org/doc/master/guide-lifetimes.html

There are no more magic pointer types, though; lifetimes are just annotations on references (&).

> On the other hand, building libraries to abstract unsafe pointers has been somewhat discredited by C++ and shared_ptr.

I think we do a lot better than C++. First of all, we believe our system is safe, unlike shared_ptr (proof is in the works). Second, shared_ptr isn't very fast, due to some design decisions like requiring atomic reference counting (which is an order of magnitude slower) and not being intrusive (requiring 2x the allocations). We also allow shared_ptr to be converted into references, allowing the programmer to eliminate a lot of reference count traffic. Most importantly, though, reference counting is something you only use if you actually need multiple references and you don't have one specific place to free the object in: in other words, you don't use reference counting in Rust much more than you'd use reference counting in C. Typical malloc/free patterns are handled with unique pointers.



"Second, shared_ptr isn't very fast, due to some design decisions like ... not being intrusive (requiring 2x the allocations)."

Not quite. You can use std::make_shared to allocate the object and the ref count in one allocation. You get improved locality of reference as an added bonus.


And it uses (or may use) a lock-free implementation on many platforms.


An atomic increment is still significantly more expensive than a normal one.


> proof is in the works

That's very exciting!




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

Search: