I have some large memory allocations in my program, and I need most of it throughout the program. So what is the best place to delete this memory? I really would not want to leave it alone.. so is WM_DESTROY
message always sent? I mean even though my application is killed by some other process..? If not please guide which is the best place to delete the memory.
-
If your application is killed, all the memory that you allocate is freed by the OS, and you can't do anything about it: you can neither help it, nor prevent it. – Kuba hasn't forgotten Monica Apr 02 '14 at 04:15
-
If your application is killed by another process, you can't do anything anyway. Other than that, `WM_DESTROY` is a good place to do clean-up. – Roger Rowland Apr 02 '14 at 04:15
-
@KubaOber yes, it is freed anyway(though OS dependent, but valid for Windows), but i think its good to free it myself. Because i no want to get into habit of asking the OS to do it as well if this habit is developed, while coding for embedded environment this is very dangorous – Apr 02 '14 at 04:21
-
"while coding for embedded environment this is very dangorous" In an embedded environment, you either have an OS that does it for you, or you don't do dynamic memory allocation (nor deallocation) after system initialization at all, and probably there's no notion of `WM_DESTROY` anyway, and probably no notion of a process either (maybe there're tasks). You're not doing anything "OS dependent", this is modern Windows of some sort, and you don't need to waste time freeing memory on process exit. Any reasonable OS with paged memory will deallocate process memory on process termination. – Kuba hasn't forgotten Monica Apr 02 '14 at 06:45
-
Besides, this is all *moot* - when your process is *killed*, you don't get to execute any code at all. That's what killing a process means: your code stops executing, and your process ceases to exist. There's nothing you can do about it, because you can't run any code. Since you can't run any code, there's no reason to even get concerned about event delivery - your message pump will not run either. – Kuba hasn't forgotten Monica Apr 02 '14 at 06:47
-
There's basically no combination of a supported OS that implements winapi and doesn't release OS resources held by a process upon termination. You're completely making this up. – Kuba hasn't forgotten Monica Apr 02 '14 at 06:49
-
@KubaOber i don't know why you sound too angry. Whatever I learned about embedded it teaches you should free up the resources that you requested, though i do not have great deal of hands-on experience in too many environments. You is senior - so probably know more.. but that does not others learning empty.. everyone does things his/her own way. Basically i think its about coding style, you like OS to do it for you I think i should clean it. I thank you for your help though. – Apr 02 '14 at 08:18
-
@user2705939: Yes, you should always free up resources you use, such as allocated memory - this should be done when you exit cleanly. Kuba is pointing out that if your process is killed, your code won't run - but in Windows, you won't/shouldn't end up with a resource leak, as Windows will clean up for you. – icabod Apr 02 '14 at 13:05
1 Answers
If an application is killed (via TerminateProcess
), your code doesn't run, so there's literally nothing you can put in your code to "clean up" things.
If an application is merely quitting after receiving WM_QUIT
, then eventually the message loop will exit and the main
(or WinMain
) function will return - thus your application-wide cleanup should be at the end of main
/WinMain
, as long as body of code within main
/WinMain
doesn't prematurely explicitly return. To assure of this, you could move the body of WinMain
(or main
) into a separate function, and invoke that from the actual main function, then do the cleanup, and finally return.
You're correct that the per-window cleanup should be done upon receiving WM_DESTROY
, but this will only happen if the window or the application was cleanly closed/quit, not terminated.
You can also use the unhandled exception filter, but this is problematic since there are no guarantees that the unhandled exception wasn't thrown due to memory corruption. There's little point to "freeing" memory when there's memory corruption already, you could, for example, end up in an endless loop.
In other words, what you're attempting to do is best described as Cargo Cult Programming. You seem to believe that there is some magic incantation that, if you just do it, will somehow protect you from "evil". Said incantation is a fantasy, a figment of your imagination. There's no code for it.

- 1
- 1

- 95,931
- 16
- 151
- 313
-
Sir thank you for your answer. But your wild imagination about this cargo cult thing is wrong. ON wiki it says _The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position_ This is definitly not case. I don't copy paste. I may accept anything else.. but please mind your words while answering. – Apr 02 '14 at 08:33
-
@user2705939: I think the "Cargo Cult" reference is related to the fact that you're trying to implement something that doesn't really serve a purpose, because there will always be a way to terminate your program without any more of your code running. I don't think it was meant as an insult - the reference is to "Programming", not "Programmer". – icabod Apr 02 '14 at 13:02
-
And, lest there be no misunderstanding: I'm sure I wrote plenty of cargo cult code myself - I know that now, didn't back then. It's a common human deficiency, it seems. Realizing one's own shortcomings and refining one's approach to problem solving is what really counts. – Kuba hasn't forgotten Monica Apr 25 '14 at 14:32
-
@KubaOber, thank you! I logged in almost after 6 months and your answer makes some sense to me. these days, I don't care about freeing the memory when my application is going to terminate, unless it is a shared resource. Sorry for misunderstanding. – Jan 02 '15 at 02:53