Hi,
On 05/11/2018 20:56, Elvis Stansvik wrote:
Den mån 5 nov. 2018 kl 20:32 skrev Konstantin Shegunov <kshegu...@gmail.com>:
Hello,
Since we couldn't agree, I'd love to see some more opinions about this one.[1]
I may be missing some detail, but I think what Thiago says makes
sense. When children are destroyed, you know you're in the QObject
destructor (from QObject::~QObject docs: "Destroys the object,
deleting all its child objects."), so you know the object is now a
QObject, no longer a QCoreApplication. If you require your
QCoreApplication to be alive by the time your child object is
destroyed, I think you have to ensure this on your own.
Problem is, I think, that this requirement is not always obvious. For
your own objects, you know you cannot rely on your parent still being a
MyClass iso of just a QObject on destruction (unless you take specific
measures to make that so), but in this case the reliance on there still
being a Q*Application around (not necessarily the parent) is usually not
as obvious as a myParent->doSomethingNotFromQObject call in your
destructor code...
Like I said, I may be missing something, but that's what it looks like
to me. I can't see why there would be an exception to the object model
here.
Elvis
Specifically:
1) Is parenting to the application object a thing?
Yes. But you know that the same goes as for any QObject parent/child
relationship: the parent is a QObject at the time of destruction (ok,
with QWidget, you're in luck).
1.a) ... and should it be allowed (i.e. accepting the proposed change)?
Yes, it should be allowed, and as you argued I think it is useful. But I
am not sure that implies the proposed change. OTOH, as so much
functionality in Qt requires the Q*Application to be alive (and that is
not always obvious) , perhaps an exception *is* in order.
1.b) .. if not allowed, should we put a warning in the documentation that it is
wrong and shouldn't be done at all, or at least that it's discouraged.
[1] https://bugreports.qt.io/browse/QTBUG-71545
I do think it makes sense to be able to do this, but if that is to be
discouraged, then best be explicit about that.
André
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
