5 ms·
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 dist
by dkhenry 14y ago
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.
- pjmlp 14y agoI fail to see how that is not reference counting, even if implemented at library level.
- mpyne 14y agoshared_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".