<p dir="ltr"><br>
On Jul 17, 2014 8:20 PM, "Zachary Turner" <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Thu, Jul 17, 2014 at 4:58 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jul 17, 2014 at 4:45 PM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
>> > In many cases there shouldn't be a need for smart pointers at all, because<br>
>> > the object is owned by a central facility's smart pointer so it's safe to<br>
>> > just pass around the pointer in ephemeral contexts like stack-based<br>
>> > instances. In such context raw pointers and references aren't scary --<br>
>> > they're just fine.<br>
>><br>
>> There's no contention there - if the pointer is non-owning, there's no<br>
>> smart pointer to use. Indeed using a smart pointer for a non-owning<br>
>> pointer would actually break the code by causing double deletes, etc.<br>
>><br>
>> Well, shared_ptr notwithstanding - but, yes, choosing between<br>
>> unique_ptr + non-owning pointers and shared_ptr can sometimes be<br>
>> non-obvious, but I'm hopeful we generally agree that if there is a<br>
>> dominating owner they can be given exclusive ownership through a<br>
>> unique_ptr and everyone else can use raw pointers.<br>
><br>
><br>
> What about weak_ptr? </p>
<p dir="ltr"> I'd generally reserve them for use when the auto-null behavior is necessary, for example in lazy caches. Though it seems the situations that call for them are relatively rare - its a good tool when you need it.</p>

<p dir="ltr">I suppose in some cases it might be nice to have something like AssertingVH that's a raw pointer in release builds and an asserting weak_ptr-like thing in debug builds.<br>
</p>