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

[Lars Knoll]

> 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.

Cheers,
Lars