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

[Konstantin Shegunov]

On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development <
development at qt-project.org> wrote:

> Oh, a nullptr deref is pretty clear in a backtrace.


Indeed, but my point is that it's relatively useless for the user (or for
the developer for that matter). As you pointed out the dev sees the nullptr
dereferencing instantly, the user just gets a crash. The assert is just
superfluous is what I'm saying.


> Even in a release
> build, if you installed the debug symbol package that does with the
> distribution's version of Qt.
>

Humor me, will you? [1]


> Please, you debug against a release build, and complain that you don't
> get debug checks?
>

To take your previous example.

QPen pen1 = ~~~;
QPen pen2 = std::move(pen1);

// ... Some code

pen1.color(); // Ooops

You're missing out on 4000 other checks that way, too!
>

Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If
not, I get segfault. And as it happens I have enough builds, so even if
that happens and I can't switch kits and step into Qt, not every one user
does have that at their fingertips, however.
Having documentation that spells such behaviour clearly, would be
satisfactory to me, that's why I was inquiring on *how* the problem, which
is a real one, can be mitigated.


> That said, I'm pretty sure that a static analyzer can find uses of
> objects in partially-formed state with local analysis.
>

QPen pen;
QColor color = pen.color();

If the analyzer can see the above as dangerous, i.e. touching an object
with an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied.

[1]:
https://packages.debian.org/search?suite=testing&section=all&arch=any&searchon=names&keywords=libqt5core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190521/588b8d76/attachment.html>