[Development] Allowing event delivery prior to and after QCoreApplication

[René J.V. Bertin]

On Tuesday April 14 2015 07:28:03 Thiago Macieira wrote:
>On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote:

>I don't know how to answer this since I have no idea what retain/release is 
>and does. Can you explain?

OK, sorry, I thought you had sufficient knowledge of ObjC programming (from before ARC made the whole retain/release mechanism largely transparent).

Simplifying things a bit, ObjC uses a refcounting mechanism to keep track of whether objects are in use or not. It also uses allocation pools (NSAutoreleasePool) which contain the list of all objects allocated since they were created; these are created automatically when you enter a runloop for instance. Unused objects are deleted only when the pool is released (or drained), and it is at that time that their "dealloc" method is called. The effect is not unlike that of QObject::deleteLater(). I'm not sure exactly what happens with objects in the pool that are still in use; I presume the pool actually hangs around until all its elements have been released.
There are some evident drawbacks to a scheme that discourages immediate deletion (and you're obliged to provide an NSAutoreleasePool in situations where they're not created for you) but it provides much better protection against things like pending events that get delivered after the destination object was deleted (cf. https://bugreports.qt.io/browse/QTBUG-44343).
It's a pity ObjC is so intricately linked to OS X, because from a few quick attempts it seems to be perfectly possible to use an ObjC++ wrapper class to extend the retain/release scheme to C++ classes.

Is this clear enough?
R.