[PATCH] D13080: [libc++] ~unique_ptr() should not set stored pointer to null
David Blaikie via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 22 17:32:33 PDT 2015
On Tue, Sep 22, 2015 at 5:26 PM, Daniel Cheng via cfe-commits <
cfe-commits at lists.llvm.org> wrote:
> dcheng added a comment.
> In http://reviews.llvm.org/D13080#251324, @dblaikie wrote:
> > I'd still be curious to see a stronger justification from the standard
> > about this.
> > I know you mentioned/quoted the definition of ~unique_ptr in the
> standard -
> > but I'm not sure that is meant to imply observable behavior during
> > destruction (though I could be wrong). Is there anything in the standard
> > about accessing objects while their dtors are executing?
> From 3.8.5 [basic.life]:
> Before the lifetime of an object has started but after the storage which
> the object will occupy has been
> allocated or, after the lifetime of an object has ended and before the
> storage which the object occupied is
> reused or released, any pointer that refers to the storage location where
> the object will be or was located
> may be used but only in limited ways. For an object under construction or
> destruction, see 12.7.
> From 12.7.1 [class.dtor]:
> For an object with a non-trivial destructor, referring to any non-static
> member or base class of the object after the destructor finishes execution
> results in undefined behavior.
> So I believe the standard permits object access while the dtor is still
Thanks for the wording - seems plausible.
My other hesitation here is: if the object being destroyed needs to use
itself through the pointer in the unique_ptr, isn't it already
fragile/broken? If the unique_ptr was reset or set to null, etc, before
destruction happened it would fail in the same way it is failing now? So
it's not safe to be held by a unique_ptr, really...
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits