1

For QObjects created on the heap with no parent, I found that destructor is not called. So, I starting using the core application instance as their parent to ensure that they are cleaned by garbage collector. Is this the right action, or what should I exactly to safely de-allocated these objects?

Here is an example of what I am doing:

// Use application instance as parent to avoid memory leak if object is not deleted
m_qObject = new DataHandler(QCoreApplication::instance());
cbuchart
  • 10,847
  • 9
  • 53
  • 93
helmeligi
  • 11
  • 4
  • *`//To avoid dangling pointer`* – What?? – J. Doe Jan 04 '20 at 21:13
  • ***//To avoid dangling pointer*** The comment is not correct (dangling pointer means something different) but the idea should work although you have to question yourself if you want these objects to be destroyed when the application closes or sooner? – drescherjm Jan 04 '20 at 23:00
  • 2
    This would work if you want the object live until the QApplication is destroyed. I can't think of many good cases for this "pattern" though, usually you would want to give the object an owner managing the (shorter) lifetime, or even create it on the stack (e.g. if created in main ()) – Frank Osterfeld Jan 05 '20 at 07:42
  • The correct term is "memory leak". not "dangling pointer" – drescherjm Jan 06 '20 at 17:09
  • @drescherjm Thank you, I was confused regarding the difference. – helmeligi Jan 06 '20 at 17:54
  • @FrankOsterfeld Yes, you are right .... I don't like the pattern. But my main question if a QObject does't have a parent, will it cause memory leak if not deleted? or does Qt framework take care of it e.g. similar to a shared pointer? – helmeligi Jan 06 '20 at 17:58
  • @helmeligi objects without parent are leaked if not explicitly managed (manual delete, shared ptr etc) in your code – Frank Osterfeld Jan 06 '20 at 20:13
  • It will be leaked. Your OS will most likely cleanup memory when your process is ended however your destructors will not be called for these leaked objects. – drescherjm Jan 06 '20 at 22:07
  • Thanks a lot guys, it is clear for me now. – helmeligi Jan 07 '20 at 17:49

1 Answers1

1

Qt doesn't have an independent memory management, such as a garbage collector. The explicit parent-child relationship used is a classic ownership model that helps in the automatization of object life-cycles, it is deterministic (it will delete object on parent's destruction), and it is very natural with user interfaces.

If an object is created (in the heap) without a parent, it will generate a memory leak when the last reference to it is lost. Objects in the stack should not have a parent to prevent double-delete errors (check Qt documentation for further information)

If you set QApplication::instance as the parent of an object, you are basically telling it not to be destroyed until the application quits. If that's the case, then there is no such a great difference with other standard memory leaks, escept the object's destructor does something else than just releasing memory (such as closing OS-wide handles, saving files, etc).

There is a very interesting case I was curious about: what happened when the original parent (Q*Application::instance) was replaced at any given moment, as in this question?

The case is that the ownership of the object is transferred from the former Q*Application instance to the new one. It may become a problem if you rely on the existence of the object through the whole application life-span but several instances of Q*Application are allowed to be created and destroyed at any moment. One scenario would be a non-Qt application loading plug-ins or components built on Qt, in where you cannot control the creation/destruction order.

If that's the case, I'd suggest to find another way to destruct your object, such as having your own singleton inheriting from QObject that you can use as parent.

cbuchart
  • 10,847
  • 9
  • 53
  • 93