Re: [Boost-users] [smart_ptr] weak_ptr pointer semantics

Subject: Re: [Boost-users] [smart_ptr] weak_ptr pointer semantics
From: Andrew Holden (aholden_at_[hidden])
Date: 2011-11-11 09:46:06

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?