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

Best regards

More information about the Development mailing list