I've been playing w/ Rust this past week, and I've had something of an enlightening experience related to the pointer semantics you describe.
Rust's memory management works similarly to what you describe in C++[0], but things like unique_ptr, et al. are baked into the syntax and compiler. -- It's basically syntactic sugar for memory semantics.
Coming from a background of GC'd languages (Java, Go, and Ruby) these different allocation semantics were Very Hard(TM) for me to understand at first.
I kept battling w/ the type checker, throwing different pointer types at it until the example compiled. (Rust's compiler is _very_ intelligent, w/o using "unsafe" code, you basically cannot have a "use after free" condition in Rust. -- It will not compile.)
As the parent points out: I've never really spent any length of time _understanding_ the allocations I'm asking a computer to make. I just generate things, they become garbage, and the runtime cleans it up eventually.
Once Rust "clicked" for me, I realized something: I know the lifetime of _every single variable_ in this piece of code.
I know when it's allocated, where it's allocated, and when it gets freed.
The reason it was so hard for me to initially grok Rust was because I'm _not used to reasoning_ about memory allocation.
Once I understood the semantics though, it was as though I had an _entirely new_ level of abstraction at my fingertips.
These semantics are definitely some powerful stuff, and I'm very glad I'm taking the time to try and understand them.
Or you can do what c++ and rust did which is neither reference counting or GC ( yes I know rust has a GC just stay with me for a little). Its a strong and distinct message about what you plan on doing with the memory your getting. When I run across a int* i don't know what your doing with it just by seeing its type, but if I run across a shared_ptr<int> I know its reference counted and will stick around until I am done with it and if I am the last one it will be free'd. In the same manner If i see a unique_ptr<int> I know that if i need it I must take it from someplace and the compiler will be kind enough to tell me if I messed it up somehow.
shared_ptr probably does use reference counting, but unique_ptr doesn't.
There's literally only ever one "owner" of a unique_ptr, which is why the parent comment talked about taking it from somewhere.
C++ exchanges ownership of unique_ptr's in the move constructor or assignment operator (i.e. there's no "copy" operation available, unlike with std::auto_ptr). If a unique_ptr still happens to own a pointer when the unique_ptr is destructed, it knows to destroy the pointed-to object as well and free the memory, but the object itself is not reference-counted per se, there's only the Boolean sense "alive/dead".
Rust's memory management works similarly to what you describe in C++[0], but things like unique_ptr, et al. are baked into the syntax and compiler. -- It's basically syntactic sugar for memory semantics.
Coming from a background of GC'd languages (Java, Go, and Ruby) these different allocation semantics were Very Hard(TM) for me to understand at first. I kept battling w/ the type checker, throwing different pointer types at it until the example compiled. (Rust's compiler is _very_ intelligent, w/o using "unsafe" code, you basically cannot have a "use after free" condition in Rust. -- It will not compile.)
As the parent points out: I've never really spent any length of time _understanding_ the allocations I'm asking a computer to make. I just generate things, they become garbage, and the runtime cleans it up eventually.
Once Rust "clicked" for me, I realized something: I know the lifetime of _every single variable_ in this piece of code.
I know when it's allocated, where it's allocated, and when it gets freed.
The reason it was so hard for me to initially grok Rust was because I'm _not used to reasoning_ about memory allocation.
Once I understood the semantics though, it was as though I had an _entirely new_ level of abstraction at my fingertips.
These semantics are definitely some powerful stuff, and I'm very glad I'm taking the time to try and understand them.
[0]: http://pcwalton.github.com/blog/2013/03/18/an-overview-of-me...