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

[Simon Hausmann]

Hi,

I favor a well-formed (null) state over a partially-formed state. I agree with the suggestion of adding null pointer checks into member functions where applicable.

I think a well-formed state is more likely to enable our users to have a productive time. Operating - by accident - on a partially-formed object and either

    (1) seeing a back-trace that points into Qt, not my application code

    (2) spending time in the debugger stepping through Qt code

is IMHO a direction that we should avoid.


Simon
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Giuseppe D'Angelo via Development <development at qt-project.org>
Sent: Sunday, May 19, 2019 14:24
To: development at qt-project.org
Subject: [Development] What's the status of a moved-from object?

Hi,

I'm trying to find a resolution for

> https://codereview.qt-project.org/#/c/261564/

TL;DR: the patch removes the move constructor from QColorSpace, because
that move constructor leaves the moved-from object in a partially-formed
state.

I have nothing against that idea (on the contrary), but I am against the
principle of introducing such inconsistencies in Qt without a previous
agreement.

Hence, I'll ask here: what should the status of a moved-from object be?
I'm not really interested in _how_ to achieve such status (although of
course it's very important, and should influence the decision); I'm
interested in what's our contract with our users.

A few datapoints for discussion are in the patch comments.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190523/cccb307a/attachment.html>