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

On January 29, 2016 3:35:54 PM EST, Emil Dotchevski wrote:

On Fri, Jan 29, 2016 at 1:40 AM, Rob Stewart wrote:

...

On January 29, 2016 2:48:56 AM EST, Emil Dotchevski < emildotchevski@gmail.com> 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)