On Fri, Jan 29, 2016 at 1:40 AM, Rob Stewart
On January 29, 2016 2:48:56 AM EST, Emil Dotchevski < emildotchevski@gmail.com> wrote:
On Thu, Jan 28, 2016 at 7:57 PM, Michael Marcin
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