Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-01-29 15:35:54
On Fri, Jan 29, 2016 at 1:40 AM, Rob Stewart <rob.stewart_at_[hidden]>
> On January 29, 2016 2:48:56 AM EST, Emil Dotchevski <
> emildotchevski_at_[hidden]> wrote:
> > On Thu, Jan 28, 2016 at 7:57 PM, Michael Marcin
> > <mike.marcin_at_[hidden]>
> > wrote:
> > > On 1/28/2016 8:09 PM, Emil Dotchevski wrote:
> > The point of shared_ptr is to be able to reason that as long as you
> > hold on
> > to a shared_ptr (which you might get by copying another shared_ptr or
> > by
> > locking a weak_ptr), the object will not expire, but you don't hold on
> > to
> > it longer than you need to. This reasoning is perfectly valid within
> > the scope of do_something.
> If do_something() saves a copy of the shared pointer in a container, for
> example, later references will refer to a non-existent object. There's
> nothing you can do about it short of using assertions or another runtime
> check with a call to std::terminate() or similar. That's hardly ideal.
That's hardly a problem if it never happens. :)
> > At any rate, what other use of null_deleter can you think of? Are you
> > saying that null_deleter makes no sense?
> I've used it to refer to static objects, but never to automatic variables.
Static objects do get destroyed, except only God knows in what order, so
strictly speaking you can't know that shared_ptr references to them won't
exist after they get destroyed. Consider that if you pass a shared_ptr to a
function, it can copy it to a global shared_ptr. At least with local
objects you can assert on unique().
The point of null deleter is specifically to be able to use shared_ptr in
cases when it isn't possible for shared_ptr to control the lifetime of the
object. I don't think of the lack of safety as a disadvantage, it's a
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk