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

Konstantin Ritt ritt.ks at gmail.com
Tue May 21 14:00:19 CEST 2019


вт, 21 мая 2019 г., 14:25 Mutz, Marc via Development <
development at qt-project.org>:

> On 2019-05-21 13:03, Konstantin Ritt wrote:
> > вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
> > <development at qt-project.org>:
> >
> >> And while the partially-formed
> >> state can be extended to non-pimpled classes easily:
> >>
> >> class QRect {
> >> int x, y, w, h;
> >> public:
> >> QRect() = default;
> >> };
> >> QRect r; // partially-formed
> >> r.x();   // compilers _already_ warn about this
> >> QRect r = {}; // zero-initialized
> >>
> >> That
> >> should be modelled by optional<QRect>, not by QRect itself.
> >
> > Whilst the statement feels reasonable, this will require tons of API
> > changes and double checks on the user side:
>
> There are no double-checks. If the old code didn't check the rect before
> using it, it was a bug.
>

the first one is "does returned optional contain a rect?"
the second one "is rect empty?" // <- same check that was done in the "old"
code


> > optional<QRect> Item::childrenRect() const
> > {
> >     if (hasChildren()) {
> >         QRect r = {};
> >         for (auto *child : children())
> >             r.unite(child->boundingRect().value_or({});
>
>    for (auto *child : children())
>        if (auto rect = child->boundingRect())
>            r.unite(*rect);
>
> >         return r;
> >     }
> >     return nullopt;
> > }
> >
> > QRect r = item->boundingRect().value_or({});
> > if (!r.isEmpty())
> >     ~~~
>
> if (auto r = item->boundingRect())
>      use(*r);
>

there is nothing to use if 'r' has no value.
> The behavior is undefined if *this does not contain a value.
-- so value_or({}).
and then one would have to check if '*r' is valid/empty/normalized, just
like (s)he did before.


> > Note that I'm ok with that, but should we enforce such a huge efforts
> > all over Qt API just for making the default-constructible QRect a
> > no-op?
>
> This is not proposed for Qt 6. Not by me, at least. But it's the logical
> extension and once Qt can depend on C++17, iow: std::optional, it's the
> correct way forward, IMNSHO.
>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190521/de028492/attachment.html>


More information about the Development mailing list