Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2016-01-30 05:20:20

On January 29, 2016 3:35:54 PM EST, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
> 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:
>
> > 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. :)

True enough.

> > > 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.

Also true. Implied in my statement is knowledge, like you apparently implied with do_something(), that the all shared_ptrs will be destroyed before the referenced object is destroyed. In the case I was thinking about, the plugin framework releases the shared_ptr before unloading the dynamic library containing the static object.

> 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().

Granted

> 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.

I wouldn't go that far, but you're right that it's an example of "trust the programmer."

___
Rob

(Sent from my portable computation engine)