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

On January 29, 2016 2:48:56 AM EST, Emil Dotchevski wrote:

On Thu, Jan 28, 2016 at 7:57 PM, Michael Marcin 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)