Boost logo

Boost :

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-29 04:40:14


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:
> >
> >> And it's way too easy to break that guarantee because it's not the
> >>> semantics that shared_ptr was designed for.
> >>>
> >>>
> >> {
> >> foo local;
> >> shared_ptr<foo> pl(&local,null_deleter());
> >> ....
> >> do_something(p);
> >> ....
> >> assert(pl.unique());
> >> }
> >>
> >> Yes, in the presence of exceptions one must also
> assert(pl.unique()) in a
> >> catch(...), and yes, compile-time errors are better than run-time
> errors,
> >> but I wouldn't sacrifice the availability of weak_ptr and the
> capacity of
> >> shared_ptr to act as THE single smart pointer framework in a
> program.
> >>
> > Why on earth would you ever do this?
>
> One reason is to get weak_ptr.
>
> > There is no shared ownership semantics here at all.
>
> 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.

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

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk