Subject: Re: [boost] Looking for thoughts on a new smart pointer:shared_ptr_nonnull
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-10-10 18:12:34
On 10/11/2013 4:00 AM, Quoth Nevin Liber:
> In general, destructors are written assuming the invariants of the class
> hold on entry to the destructor.
And..? If the constructor of an object throws, its destructor is not
invoked. So all destructors that are called should still have good
It's only if you *don't* throw from the constructor that you'll have a
problem, because now you *do* have an object with an invalid invariant.
(And if "my internal pointer is non-null" is not an invariant of this
class, then it has no reason to exist.)
> In order for what you say about stack unwinding to be true, you have to
> assume that the null pointer isn't due to a broken invariant somewhere
> else. Where is your evidence that no other object or program invariants
> are broken?
Where is your evidence that they are?
Given that this must (by definition) be the first time that this
particular pointer has been assigned to a "must be non null" smart
pointer object, everything else higher up the call stack either must not
be using the pointer or must be ok with the idea that it could be null,
otherwise the problem would have been encountered earlier.
> Data corruption is a far worse user experience.
Granted. But there shouldn't be any of that here, unless the programmer
doesn't write their higher-level catch handler properly.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk