QMainWindow can't appear in front of child QWidget
-
This will automatically close all windows.
But will it free the memory associated with each of them?
@kshegunov said:
This will automatically close all windows.
But will it free the memory associated with each of them?
Hmm... not directly, I guess.
I know that there's an ongoing debate about whether or not it's appropriate to let the OS reclaim some unfreed memory upon program shutdown. I'm in the camp that thinks this is OK.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@kshegunov said:
This will automatically close all windows.
But will it free the memory associated with each of them?
Hmm... not directly, I guess.
I know that there's an ongoing debate about whether or not it's appropriate to let the OS reclaim some unfreed memory upon program shutdown. I'm in the camp that thinks this is OK.
-
This could probably be cleaned up very easily with something like this (haven't tested):
... a.exec(); qDeleteAll(a.topLevelWidgets());assuming all the windows, including main window, are created on the heap and have no parents.
-
@kshegunov said:
This will automatically close all windows.
But will it free the memory associated with each of them?
Hmm... not directly, I guess.
I know that there's an ongoing debate about whether or not it's appropriate to let the OS reclaim some unfreed memory upon program shutdown. I'm in the camp that thinks this is OK.
@JKSH said:
But will it free the memory associated with each of them?
Hmm... not directly, I guess.
I know that there's an ongoing debate about whether or not it's appropriate to let the OS reclaim some unfreed memory upon program shutdown. I'm in the camp that thinks this is OK.
This won't work for me, as I have various RAII style classes which save settings to disk, etc in their destructors.
If the containing window's destructor doesn't get called, then these classes won't destruct, and the settings won't get saved.
Some windows are opened and closed during the app's lifetime - so I also don't want to wait until application shutdown to reclaim memory.
Thanks for the input though - it is appreciated, even if it doesn't fit my needs on this particular occasion exactly!
-
This could probably be cleaned up very easily with something like this (haven't tested):
... a.exec(); qDeleteAll(a.topLevelWidgets());assuming all the windows, including main window, are created on the heap and have no parents.
@Chris-Kawa said:
This could probably be cleaned up very easily with something like this (haven't tested):
... a.exec(); qDeleteAll(a.topLevelWidgets());assuming all the windows, including main window, are created on the heap and have no parents.
I just discovered that direct deletions can cause QComboBox (and possibly other complex widgets) to crash.
I think part of the reason is that the QComboBox instantiates a QComboBoxPrivateContainer, which also becomes a top-level widget. There's probably a double-deletion somewhere if we use a direct deletion instead of
deleteLater()(I haven't dug too deep to find out).So, manually deleting widgets after the event loop ends is a no-go :-/
@skebanga said:
Thanks for the input though - it is appreciated, even if it doesn't fit my needs on this particular occasion exactly!
No worries, that's what discussions are for :-) All the best with your project!
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@Chris-Kawa said:
This could probably be cleaned up very easily with something like this (haven't tested):
... a.exec(); qDeleteAll(a.topLevelWidgets());assuming all the windows, including main window, are created on the heap and have no parents.
I just discovered that direct deletions can cause QComboBox (and possibly other complex widgets) to crash.
I think part of the reason is that the QComboBox instantiates a QComboBoxPrivateContainer, which also becomes a top-level widget. There's probably a double-deletion somewhere if we use a direct deletion instead of
deleteLater()(I haven't dug too deep to find out).So, manually deleting widgets after the event loop ends is a no-go :-/
@skebanga said:
Thanks for the input though - it is appreciated, even if it doesn't fit my needs on this particular occasion exactly!
No worries, that's what discussions are for :-) All the best with your project!
@JKSH said:
I just discovered that direct deletions can cause QComboBox (and possibly other complex widgets) to crash.
I think part of the reason is that the QComboBox instantiates a QComboBoxPrivateContainer, which also becomes a top-level widget.
This is certainly curious. Maybe I can ask something ... suppose you create a widget on the stack and don't give it a parent. And after the constructor runs you add it to a layout (which I believe should take the ownership of said widget away). Does this widget count as top-level, and does it acquire a native handle (i.e. it is a native widget)? I should think not, or am I in error? Am I correct in assuming that its alien/native status is undefined until
QWidget::createis run? -
I know that there's an ongoing debate ... I'm in the camp that thinks this is OK
I don't know of such debate, but I suppose I'd be on the side opposite to yours. However, I'll grant you, it should be okay either way.
@kshegunov It does not matter. What if an application crashes? Who cleans up the memory in that case? Who closes the file descriptors? Who closes all network connections? Who frees up file locks or locks of devices like a serial device, an USB-port …?
Guess? It is easy!
It is the operating system. It is always the operating system, yo do not have to free all resources before exiting the application.
If the operating system would not, your computer/smartphone/whatever would get filled up with chunk after a few crashes and would refuse to start new applications due to lack of memory or due to locked files ...
And no! MS-DOS was not an operating system. MS-DOS was some kind of runtime library, since it did not clean up those resources, at least not all.
So do not waste your time with such discussions.
-
@kshegunov It does not matter. What if an application crashes? Who cleans up the memory in that case? Who closes the file descriptors? Who closes all network connections? Who frees up file locks or locks of devices like a serial device, an USB-port …?
Guess? It is easy!
It is the operating system. It is always the operating system, yo do not have to free all resources before exiting the application.
If the operating system would not, your computer/smartphone/whatever would get filled up with chunk after a few crashes and would refuse to start new applications due to lack of memory or due to locked files ...
And no! MS-DOS was not an operating system. MS-DOS was some kind of runtime library, since it did not clean up those resources, at least not all.
So do not waste your time with such discussions.
It does not matter.
It does, and it's proven in the OP's final post, where he notes he has clean-up code running in the destructors of his objects.
What if an application crashes?
Then the application has a bug and that needs to be addressed.
Who cleans up the memory in that case? Who closes the file descriptors? Who closes all network connections? Who frees up file locks or locks of devices like a serial device, an USB-port …?
The programmer should do that. Some OS-es do it as a safety net to leave things consistent, but certainly not all and certainly not always!
yo do not have to free all resources before exiting the application.
This claim is a bit presumptuous, to put it mildly. And if you ask me it is a lazy, and not very smart thing to do. No one referenced MSDOS at any of the posts, but if you had ever used some code that uses global resources, you'd know that it's a good idea to clean up your mess, especially if someone is trying to shut you down forcefully!
What do you think happens if an application crashes (or is terminated) while holding a reference to a global mutex? Do you think the OS knows that the global mutex must be unlocked? Suppose it's a real-time sensitive program used for air traffic meteorological information, so what do we do then? (I had such a case where someone writing the controlling UI decided it's a good idea to terminate me forcefully) Are we saying "well, wait a bit until I restart the OS"? It can make all the difference in the world if the pilot is flying through a storm, you should think about it next time you board.
-
It does not matter.
It does, and it's proven in the OP's final post, where he notes he has clean-up code running in the destructors of his objects.
What if an application crashes?
Then the application has a bug and that needs to be addressed.
Who cleans up the memory in that case? Who closes the file descriptors? Who closes all network connections? Who frees up file locks or locks of devices like a serial device, an USB-port …?
The programmer should do that. Some OS-es do it as a safety net to leave things consistent, but certainly not all and certainly not always!
yo do not have to free all resources before exiting the application.
This claim is a bit presumptuous, to put it mildly. And if you ask me it is a lazy, and not very smart thing to do. No one referenced MSDOS at any of the posts, but if you had ever used some code that uses global resources, you'd know that it's a good idea to clean up your mess, especially if someone is trying to shut you down forcefully!
What do you think happens if an application crashes (or is terminated) while holding a reference to a global mutex? Do you think the OS knows that the global mutex must be unlocked? Suppose it's a real-time sensitive program used for air traffic meteorological information, so what do we do then? (I had such a case where someone writing the controlling UI decided it's a good idea to terminate me forcefully) Are we saying "well, wait a bit until I restart the OS"? It can make all the difference in the world if the pilot is flying through a storm, you should think about it next time you board.
@kshegunov Yes, there are cases where the application crashed caused by some cleanup code which gets called within exit() (which is still the application and not the OS itself).
And yes, globally shared things like Shared Memory, Semaphores, Named Pipes and such are not cleaned up, but those are intended to be used by multiple processes to communicate. They cannot be cleaned, because they are not owned exclusive by a program.
I mentioned DOS, because of history. Back in DOS-times you had to clean up everything before exiting, otherwise you had to reboot the machine very often. That time I hacked a few Terminate-and-Stay-Resident programs, it was a hell!
-
IMO it's a code smell to rely on the OS to clean up for you.
We run all of our unit tests through valgrind as part of our build process, so that a memory leak breaks the build.
QT leaves a ridiculous amount of memory lying around, which of course kicks off valgrind.
We've got a huge suppressions file which we have to install for every GUI related unit test, and the sheer number of suppressions makes valgrind run slower, so has resulted in longer build times.
So yeah, in my opinion, it would be nice if QT didn't do that.
