[Development] What's the status of a moved-from object?
Allan Sandfeld Jensen
kde at carewolf.com
Mon May 20 21:05:58 CEST 2019
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.
More information about the Development