Use of QObject.deleteLater()

I've seen in some of the code samples where the method QObject.deleteLater() is sometimes used.  For example,

I was looking at the sample "Save a Pose Preset", and at the bottom there's a line where an asset IO filter is deleted:

// Clean up; do not leak memory
oAssetIOFilter.deleteLater();

 

I'm curious to know exactly how often should I use this method?  And on what kind of objects?  I used to think that

Javascript (and DAZ Script) would automatically clean up most kinds of objects once they were created, used and

went out of scope, but now I'm a little confused.

 

Comments

  • OmnifluxOmniflux Posts: 377

    I have not found this documented anywhere. Here is the list of objects I have come across which the sample scripts call deleteLater() on.

    • DzAssetIOFilter
    • DzDir
    • DzFileInfo
    • DzImporter
    • DzExporter
    • DzScript

     

     

  • DafaDafa Posts: 97

    I found that confusing myself. Is there a general rule when to explicitly delete objects? 

     

  • jbowlerjbowler Posts: 794

    Dafa said:

    I found that confusing myself. Is there a general rule when to explicitly delete objects? 

    Qt experts please correct if/when I get this wrong:

    • If the object has a parent then it is not necessary to delete it, however it may be deleted.
    • If the object does not have a parent then it needs to be deleted explicitly, though "explicitly" can be as simple as setting WADeleteOnClose on a window.

    "deleteLater" is a separate and, perhaps, more important issue.  Objects can be deleted, the destructor of the object informs the parent of the object that it is a dead parrot and the parent deletes the perch.  Typically, however, objects can be in use, for example something else on the call stack might have a pointer to them.  This might not be an issue in DAZ Studio scripting however it certainly is in C++ Qt programming.  The Qt "deleteLater" concept basically pushes the delete up the C++ stack until it meets the event loop; by this time there should not be any outstanding C++ pointers.  I imagine that DAZ Studio exposes "deleteLater" to avoid stuff in its own stack segfaulting as a result of a script delete but I don't know enough about DAZ Scripting to comment more on that.

  • Richard HaseltineRichard Haseltine Posts: 100,842

    I am told that it actually depends on ownership https://doc.qt.io/qt-5/qscriptengine.html#ValueOwnership-enum and since that is not documented it is best just to follow the samples.

  • Richard HaseltineRichard Haseltine Posts: 100,842

    If, for instance, you instantiate DzNode but do not add it to the scene... it has no owner, and so you would need to call deleteLater() on that instance because it is not owned by the script (or anything else) and it would not be cleaned up by garbage collection or when the script goes out of scope - it would "leak." Similar situation with a DzProperty not being added to a DzElement, a DzObject not being added to a DzNode, etc. In some cases the documentation does inform of the fact that the responsibility lay with the caller, such as DzExportMgr::findExporter().

  • jbowlerjbowler Posts: 794

    Richard Haseltine said:

    I am told that it actually depends on ownership https://doc.qt.io/qt-5/qscriptengine.html#ValueOwnership-enum and since that is not documented it is best just to follow the samples.

    That's the documentation for Qt5, which DAZ does not use; my understanding is that DAZ is based on Qt 4.8.  This utexas web page is specifically about 4.8 and is probably somewhat more helpful than Qt documentation (Qt seems to be at least hiding the Qt4 documentation):

    https://het.as.utexas.edu/HET/Software/html/scripting.html#qt-ownership

    That page seems to answer the OP's question.

     

Sign In or Register to comment.