Hi,

Il 19/05/19 14:24, Giuseppe D'Angelo via Development ha scritto:
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.


Trying to summarize the discussion so far. It seems to me that there's some agreement on these points:

1) We want move constructors for pimpled valued classes.

2) They must be noexcept, incl. not allocating memory.

3) At least for Qt 6's lifetime, the documented state of a moved-from object is "valid, but unspecified", à la stdlib, and NOT partially-formed. Any function without preconditions can be called on a moved-from instance; the results are unspecified. ("Unspecified" used in Standardese jargon here).

4) We will deliberately break source compatibility by adding move constructors to the classes currently lacking them (and thus copying instead of moving; leaving the source object in a well-defined state).

Hopefully, in the next years, static and runtime analyzers will be able to catch more and more usages of use-after-move. If we're really paranoid about this we could hide the move constructors behind a macro to avoid the SC break.

===

With these constraints, then we're left with "how do we do it"?

A) Allow for the d pointer to be nullptr; that's what gets set in the source object. To keep the object valid, this means checking the d pointer for nullptr in any function without preconditions (... read: in any member function, better safe than sorry). The cost of these extra checks is to be determined.

B) Introduce a "shared_null" for every pimpled class, under the form of a Q_GLOBAL_STATIC or similar. The move constructor resets the source object's d pointer to that shared_null.

As a by-product, both A) and B) can be used to make the default constructor not allocate and noexcept.


Am I forgetting anything?

Thank you,
--
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

Attachment: smime.p7s
Description: Firma crittografica S/MIME

_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to