Freeing up memory for global variables
-
@mpergand said in Freeing up memory for global variables:
If you have only one window, your app will quit as soon as this window is closed (default behavior of QApplication)
Untested, but doesn't
QWidget *widget = new QWidget; return app.exec()leak thenewed widget/window (e.g. for valgrind) if you don'tdeleteor set auto-delete on close on it? -
@mpergand said in Freeing up memory for global variables:
If you have only one window, your app will quit as soon as this window is closed (default behavior of QApplication)
Untested, but doesn't
QWidget *widget = new QWidget; return app.exec()leak thenewed widget/window (e.g. for valgrind) if you don'tdeleteor set auto-delete on close on it?@JonB said in Freeing up memory for global variables:
Untested, but doesn't QWidget *widget = new QWidget; return app.exec() leak the newed widget/window (e.g. for valgrind) if you don't delete or set auto-delete on close on it?
If nobody deletes it, it is leaked. I would hope that valgrind would catch it (haven't used valgrind on real projects, yet). However, it is really annoying if you close an application and it takes a couple of seconds to actually disappear because it is doing all kinds of clean up. The operating system will reclaim all memory anyway. So, I'm in the camp of "don't clean up after yourself" when closing your application. Not as a hard rule, but certainly as a place for optimization of the user experience.
-
D DmitryTS has marked this topic as solved on
-
@mpergand said in Freeing up memory for global variables:
If you have only one window, your app will quit as soon as this window is closed (default behavior of QApplication)
Untested, but doesn't
QWidget *widget = new QWidget; return app.exec()leak thenewed widget/window (e.g. for valgrind) if you don'tdeleteor set auto-delete on close on it? -
@JonB I just read about QScopedPointer and there was such an example, do I understand correctly that the QWidget will a priori be created through smart pointers and therefore there will be no problems with clearing memory?!
@DmitryTS None of these pairs of lines are equivalent. A QScopedPointer deletes the object it points to when it is destroyed.
A raw pointer that is destroyed because it gets out of scope does not trigger the deletion of the objects it points to. You have to explicitly use
deleteon it before. -
@JonB said in Freeing up memory for global variables:
Untested, but doesn't QWidget *widget = new QWidget; return app.exec() leak the newed widget/window (e.g. for valgrind) if you don't delete or set auto-delete on close on it?
If nobody deletes it, it is leaked. I would hope that valgrind would catch it (haven't used valgrind on real projects, yet). However, it is really annoying if you close an application and it takes a couple of seconds to actually disappear because it is doing all kinds of clean up. The operating system will reclaim all memory anyway. So, I'm in the camp of "don't clean up after yourself" when closing your application. Not as a hard rule, but certainly as a place for optimization of the user experience.
@SimonSchroeder , @mpergand
And I am not of the camp who say "don't bother to delete when you are exiting because everything gets destroyed anyway". Thereby hangs the indistinguishability of what are "genuine" leaks in your code versus ones which you choose not to count as leaks because they are "top-level" or "you know about them". It seems to me there are two possible situations:- There is only "one" top-level/global allocated variable: in which case it's one line of code to free it and it won't take any time.
- There are "hundreds" of such, or in some "hierarchy": in which case I revert to if you don't free them you won't be able to see anything left over which are your "genuine" leaks.
We are, of course, all entitled to our styles/opinions. I really don't see how you use valgrind or equivalent properly with your approach. If you really feel it could take too long in production then at least write the disposal code in a
#ifdefor run-time conditional check which you check during development/analysis and disable for end-user.@DmitryTS
So there you are: you have different opinions. As @SGaist says your examples ofQScopedPointerare not the same as the non-ones. You can use it if you wish, but my own feeling is while you are learning it does little harm to write explicit code to do the deleting.In itself this has little to do with why you want "global variables" in the very first place.
-
@DmitryTS None of these pairs of lines are equivalent. A QScopedPointer deletes the object it points to when it is destroyed.
A raw pointer that is destroyed because it gets out of scope does not trigger the deletion of the objects it points to. You have to explicitly use
deleteon it before.@SGaist Did I understand correctly, that the QWidget object will not be deleted, if there is the following example, and I will first need to explicitly delete it using delete?
int main()
{
QApplication a(…);
QWidget *myWidget = new QWidget;
QScopedPointer <myWidget> pSmart;
return a.exec();
} -
@SimonSchroeder , @mpergand
And I am not of the camp who say "don't bother to delete when you are exiting because everything gets destroyed anyway". Thereby hangs the indistinguishability of what are "genuine" leaks in your code versus ones which you choose not to count as leaks because they are "top-level" or "you know about them". It seems to me there are two possible situations:- There is only "one" top-level/global allocated variable: in which case it's one line of code to free it and it won't take any time.
- There are "hundreds" of such, or in some "hierarchy": in which case I revert to if you don't free them you won't be able to see anything left over which are your "genuine" leaks.
We are, of course, all entitled to our styles/opinions. I really don't see how you use valgrind or equivalent properly with your approach. If you really feel it could take too long in production then at least write the disposal code in a
#ifdefor run-time conditional check which you check during development/analysis and disable for end-user.@DmitryTS
So there you are: you have different opinions. As @SGaist says your examples ofQScopedPointerare not the same as the non-ones. You can use it if you wish, but my own feeling is while you are learning it does little harm to write explicit code to do the deleting.In itself this has little to do with why you want "global variables" in the very first place.
@JonB I fully agree - not cleaning stuff up on exit will only harm memory leak debugging and may also lead to crashes now and then on exit due to wrong order of deletion.
-
@SGaist Did I understand correctly, that the QWidget object will not be deleted, if there is the following example, and I will first need to explicitly delete it using delete?
int main()
{
QApplication a(…);
QWidget *myWidget = new QWidget;
QScopedPointer <myWidget> pSmart;
return a.exec();
}@DmitryTS said in Freeing up memory for global variables:
Did I understand correctly
No. You misunderstood what @SGaist wrote.
In that code snippet the QWidget will be deleted because of QScopedPointer. -
@SimonSchroeder , @mpergand
And I am not of the camp who say "don't bother to delete when you are exiting because everything gets destroyed anyway". Thereby hangs the indistinguishability of what are "genuine" leaks in your code versus ones which you choose not to count as leaks because they are "top-level" or "you know about them". It seems to me there are two possible situations:- There is only "one" top-level/global allocated variable: in which case it's one line of code to free it and it won't take any time.
- There are "hundreds" of such, or in some "hierarchy": in which case I revert to if you don't free them you won't be able to see anything left over which are your "genuine" leaks.
We are, of course, all entitled to our styles/opinions. I really don't see how you use valgrind or equivalent properly with your approach. If you really feel it could take too long in production then at least write the disposal code in a
#ifdefor run-time conditional check which you check during development/analysis and disable for end-user.@DmitryTS
So there you are: you have different opinions. As @SGaist says your examples ofQScopedPointerare not the same as the non-ones. You can use it if you wish, but my own feeling is while you are learning it does little harm to write explicit code to do the deleting.In itself this has little to do with why you want "global variables" in the very first place.
@JonB thanks, global var of course it is used , I just took a micro piece, I just want to figure out how they can be cleared, since I cannot change these global variables, they are used in 10,000 lines, and most of all they are used for qml components( calling some additional functions),
in principle, all the work is done on a very old version of qt, and the launch comes from a docker container, where there is not even valgrind :( -
A global scoped pointer to a QObject will be destroyed after QCoreApplication is gone so it will likely crash. Fix your code and don't use global variables.
