|
Boost : |
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]>
wrote:
> 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
feature.
Emil
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk