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 <sas...@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.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development