Menu
Does the new memory allocated always get freed up when program closes? (even if closes unexpectedly from a bug/error etc, or custom close functions)?
Or does it only free the memory if it returns from main?
869
Most memory on most OSes however will be automatically reclaimed when the process exits.
Everything gets deallocated when the program exits, by the operating system, not the compiler.
In these cases, even small chunks of storage add up and create a problem. Thus our usable space decreases. This is also called “memory leak”. It may also happen that our system goes out of memory if the de-allocation of memory does not take place at the right time.
When your program ends all of the memory will be freed by the operating system. The reason you should free it yourself is that memory is a finite resource within your running program. Sure in very short running simple programs, failing to free memory won't have a noticable effect.
Are you running on a desktop OS (Windows, Linux etc.)? If so, yes, in general the system will free any memory associated with the program when the program exits.
In both 2 cases, i think microsoft auto set when use 50% of ram, system will think low memory and auto close app when use over 60% ram. I said i saw ram free in task manager, not use bios ram.
However it is important to note that in specialized environments such as various Real-Time Operating Systems the memory may not be freed when the program is terminated. Show activity on this post.
Click the Performance tab and the Resource Monitor button. Click the Memory tab and check whether Free is near to Zero or is Zero. If it is, open RAMMap, click Empty on the Menu bar and Empty Standby list. This action instantly restores Free memory.
Yes, operating systems usually keep track of the memory allocated by each process and release it when those processes terminate - no matter how.
This, however, is not a valid reason to have memory leaks in your program in general: a program should always actively release the resources (including memory) it acquires, unless there is a really good - and documented - reason for not doing so.
Good reasons could be the dependency of a program's correctness on the order of destruction of global/singleton objects, or the expensiveness of actively freeing allocated memory before termination.
However, while admitting that there could be reasons why a programmer would intentionally avoid releasing memory, please be careful not to develop a too shallow mindset as to what counts as a "good reason" for not cleaning after yourself.
I would encourage you to get used to write code that does release the memory it acquires, and document explicitly in a very clear form every situation where you are not going to follow this practice. Again, while there might be corner-cases that require this, releasing or not releasing acquired memory always has to be an active, intentional decision of the programmer.
NOTE: Quoting Steve Jessop from the comments, another good reason why you would not want to actively release memory is when your program needs to be terminated because it somehow reached an unexpected state - perhaps one that violates an invariant, or a pre-condition of a certain function. Usually, violating a precondition means Undefined Behavior.
Since - by definition - there is no sane way to recover from UB, you may want to immediately terminate your program rather than performing further actions that could have any outcome - including highly undesirable ones.
129
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
