> On 20 May 2019, at 14:51, Mutz, Marc via Development > <[email protected]> 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 _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
