On Montag, 20. Mai 2019 20:18:32 CEST Mutz, Marc via Development wrote: > On 2019-05-20 17:16, Thiago Macieira wrote: > > On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote: > >> 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 hadn't thought of noexcept, but let's be clear: yes, move > > constructors must > > be noexcept. That might be the good reason why it can't reset to a > > valid > > state. > > What a feat it would be if Qt celebrated the 10th anniversary of the > publication of Elements of Programming with embracing the > partially-formed state :) > > So, we seem to agree that moved-from objects may have d == nullptr. In > the following, let this be our premiss. > > Where we still, maybe, disagree, is whether d == nullptr is a valid > state. The difference is whether member functions other then destruction > and assignment check for a nullptr d. I'd propose that on classes under > the above premiss, Q_D contains Q_ASSERT(d). This, I think, strikes the > best balance between safety and speed.
I agree. I would consider anything other than deleting or reassigning a moved object undefined behavior, so asserting on it seems like a good help to users of our APIs. I would add though that if the class has an isValid() method that method should be callable, and must returns false. Not sure about a possible isNull() method :/ That whole subject btw, probably needs some cleanup. Wrappers with undefined, invalid and null values have been getting a bit mixed up in Qt APIs, and that gets confusing when some the values we wrap are stuff like JSON and SQL that has defined null values. Best regards 'Allan _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
