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 <[email protected]> on behalf of Giuseppe
D'Angelo via Development <[email protected]>
Sent: Sunday, May 19, 2019 14:24
To: [email protected]
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 | [email protected] | 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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
