[Development] Qt6 source changes

[Konstantin Shegunov]

I've seen that kind of argument before, so that's why I want put a comment
in here.

On Thu, Nov 1, 2018 at 12:58 PM Sascha Cunz <sascha at cunz-rad.co.uk> wrote:

> I've seen lots of commercial code bases in the past where QObject
> inheriting classes are combined with QExplicitlySharedDataPointer -
> while at the same time relying on having a parent in those QObjects.
>

QExplicitlySharedDataPointer? That would be rather odd. Do you mean
QSharedPointer?

Semantically:
> - They are strongly owned by some other QObject based entity
>

Then that's their parent.

- A lot of code stores a reference to them (In terms of a QESDP), where
> either:

   - the reference _should_ be invalidated during destruction
>

QPointer or connect directly to `QObject::destroyed`.

   - the existence of such reference (to a child) _should_ stop the
> parent from destroying that child.
>

Then they're not strongly owned by the parent!

- The overhead of QPointer is not desirable
>

Other smart pointers are cheap?

I know these requirements are kind of a paradox. But both variants of
> this are a pattern, I find relatively often in customer's code bases.
>

Sounds more like antipattern.


> I would really like to have an easy way to give such customers a "sane"
> way forward.
>

That'd be to define the ownership clearly, not try to weasel out of it with
some "smart" pointer.
Self-owning QObject instances can still be hold in `QSharedPointer` if
needed, however,
then they're not owned by the parent, so you shouldn't give them a parent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181101/1789b089/attachment.html>