OP
Running Valgrind on two builds of my example application, one with the deletes and one without, shows the exact same number of small memory leaks, in the exact same places. So those manual deletes literally made no difference to the application.
All of the memory leaks detected and reported by Valgrind were in various syscalls and other external libraries used by QT and not directly in the example application itself.
As Valgrind saw no difference, I think it’s safe to say that the library must reparent the widgets. And the framework must be cleaning up those pointer member variables when exiting the program.
I’ll update the tutorial and the code at some point in the next few days, when I’m not relying solely on my phone. I’ll remove the manual deletes and will update the blurb.
In fact, without those deletes, the destructor is pretty pointless. So rather than leaving an empty destructor, I may as well remove it and leave the compiler to create a default destructor for that class.
All of the memory leaks detected and reported by Valgrind were in various syscalls and other external libraries used by QT and not directly in the example application itself.
As Valgrind saw no difference, I think it’s safe to say that the library must reparent the widgets. And the framework must be cleaning up those pointer member variables when exiting the program.
I’ll update the tutorial and the code at some point in the next few days, when I’m not relying solely on my phone. I’ll remove the manual deletes and will update the blurb.
In fact, without those deletes, the destructor is pretty pointless. So rather than leaving an empty destructor, I may as well remove it and leave the compiler to create a default destructor for that class.
