On Thursday, November 10, 2011 7:47 PM, Szymon Gatner wrote:
Because it is not safe to have a pointer to something and not reference count it.
Not sure what you mean here, I still have weak_ptr<> which has a counter and there is a shared_ptr<> (or not) somewhere out there. So counter exists as long as I still have any shared_ or weak_ pointer.
Not exactly. The weak_ptr reference counts an internal object, but not your object.
If you don't want safety in your pointers, then use raw pointers. If you want safety, then you have to accept the consequences...
So using get() on shared/scoped/auto/unique_ptr somehow keeps me safe having raw pointer that bypasses all protection they provide but weak_ptr is too much? Not buying it ;)
The difference is that, for shared/scoped/auto/unique_ptr, you can ensure the raw pointer remains valid by not destroying the smart pointer. Of course, it is your responsibility to keep that smart pointer around for as long as you use the raw pointer. However, a weak_ptr doesn't do anything to keep the underlying object around, and so keeping the weak_ptr doesn't guarantee the raw pointer remains valid. (from original post)
get() would return raw pointer from shared counter (so is fast) and not shared_ptr<> as lock() does.
Has a profiler (like Valgrind or VTune) verified the lock call significantly harms your performance?