[Development] What's the status of a moved-from object?

[André Pönitz]

On Mon, May 20, 2019 at 01:56:56PM +0000, Lars Knoll wrote:
> > On 20 May 2019, at 14:51, Mutz, Marc via Development
> > <development at qt-project.org> wrote:
> > 
> > On 2019-05-20 11:25, Giuseppe D'Angelo via Development wrote:
> >> Hi, Il 19/05/19 18:54, Thiago Macieira ha scritto:
> >>> But I think all Qt classes should go beyond that, unless they have
> >>> VERY good reasons not to do so (and document so). The moved-from
> >>> object should also be in a valid state so all the accessor and
> >>> mutation API in the class can operate in the object without ill
> >>> effects. What they actually do, we can't tell, since the initial
> >>> state is unknowable. So apply the principle of GIGO.
> >> So basically the same stance as the Standard Library? One should be
> >> able to invoke any function without preconditions on a moved-from
> >> object?
> > 
> > Except that the standard library has an easy way of implementing
> > that, since there're no PIMPLs. For a PIMPLed class, it means that
> > the move constructor either must allocate memory or that each and
> > every PIMPLed value class needs to have a static unsharable null
> > instance. This is relatively easy for some, but try that for QBrush.
> > Or we litter all member functions with nullptr checks.
> > 
> > I agree that a moved-from object should be in the same state as a
> > default-constructed one. I disagree with that that state must always
> > be a valid value of the class. I agree with Stepanov that the
> > default constructor should be establishing the partially-formed
> > state, ie, only destruction and assignment are valid. It _can_ do
> > more, but only if it stays noexcept.
> > 
> > Or maybe we don't disagree at all and Thiago would accept allocating
> > memory (or, by extension, anything that's noexcept(false)) as a very
> > good reason to have a nullptr d?
> 
> I actually think we should consider getting rid of shared_null and
> instead have d == nullptr as the null/default constructed state of the
> object. Yes, that means we need to check for d == nullptr in member
> functions, but I don’t think the overhead is a problem, as d will have
> to be loaded into a register in any case.

In case someone submits such change I'd appreciate some performance
checking.

Andre'