Persistence of memory leak
When I create an object with new, I know that it has to deleted, otherwise, memoryleak occurs. But, I am wondering if this memory lost, even after the program closes, or is it only lost while program is still open.
Last edited on
Modern OSs will release all memory used by a process once it closes.
So no, it won't be a "permanent" leak.
So no, it won't be a "permanent" leak.
So I don't have to delete something just before program closes. I only need to delete in the middle of the program to allow memory to be used by other programs?
Yes you do need to delete it before the program exits. If it has no side effect depends on the weather.
| If it has no side effect depends on the weather. |
What do you mean? And Why do I need it, if OS is going to free it anyways?
It depends entirely on the circumstance.
If you do not delete something, and you let the OS clean up the memory for you, then any destructors will not be called. Destructors might have side-effects that you want (like, say, logging something to a file), but those side-effects will not happen.
On the other hand, if you have thousands of allocations, deleting each of them individually might be slower than letting the OS do an overall wipe.
The biggest danger to letting the OS do it, though, is that your program model might change. You may think now that X items will only be deleted once at program exit, but in the future you might change your design so that the items get reallocated several times. Failure to be cleaning up would then cause very problematic leaks.
-------------------
Long story short: falling back to the OS is risky. I don't recommend it unless it's not feasible to do cleanup (rarely the case), or unless it really hinders shutdown performance to manually delete everything (extremely rarely the case).
...
Of course, a cautious programmer will try to use RAII techniques whenever possible so that they never have to delete anything.
If you do not delete something, and you let the OS clean up the memory for you, then any destructors will not be called. Destructors might have side-effects that you want (like, say, logging something to a file), but those side-effects will not happen.
On the other hand, if you have thousands of allocations, deleting each of them individually might be slower than letting the OS do an overall wipe.
The biggest danger to letting the OS do it, though, is that your program model might change. You may think now that X items will only be deleted once at program exit, but in the future you might change your design so that the items get reallocated several times. Failure to be cleaning up would then cause very problematic leaks.
-------------------
Long story short: falling back to the OS is risky. I don't recommend it unless it's not feasible to do cleanup (rarely the case), or unless it really hinders shutdown performance to manually delete everything (extremely rarely the case).
...
Of course, a cautious programmer will try to use RAII techniques whenever possible so that they never have to delete anything.
Last edited on
| And Why do I need it, if OS is going to free it anyways? |
| On the other hand, if you have thousands of allocations, deleting each of them individually might be slower than letting the OS do an overall wipe. |
The same thing goes for threads. I've had instances where a thread does not get shut down when the process ends and the kernel does nothing about it, but it still uses resources. The same thing goes with memory, it's best to keep it nice and tidy.
Last edited on
clanmjc brings up a good point. If you tell the program how and when to free up memory, that implementation wont* change. But, if you leave it up to the OS, it may be good now, but what happens 10 years down the road when OS implementations change? Maybe it does something completely different then.
*Anything is possible I guess, but the chances are slim.
*Anything is possible I guess, but the chances are slim.
Topic archived. No new replies allowed.