[Development] Qt6 source changes
kshegunov at gmail.com
Thu Nov 1 12:17:47 CET 2018
I've seen that kind of argument before, so that's why I want put a comment
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
> - 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
- 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
then they're not owned by the parent, so you shouldn't give them a parent.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development