Operating system frees it, but does not necessarily overwrite it, so if you have passwords etc. in memory, you should overwrite them.

Yes, any sane operating system will free up all the memory your process is currently using (as well as things like sockets, file handles, and so on, in general) upon shutdown anyway. There are many opinions on whether it makes sense to clean up on shutdown under that assumption, a few thoughts are below:

- if you ever want to take your program and refactor it into an independent module or library which may not live in its own process, then you will be glad you wrote some cleanup code, because this time the OS won't be there to do it for you (probably the most important reason)

- on the other hand, if you have very complex datastructures with lots of independent blocks of allocated memory floating around, it may take a while for your program to get around to deallocating them all the usual way (think of those games that take 10-15 seconds to close), whereas the OS itself just sees a big block of virtual memory and can just deallocate it all in one shot, this is mitigated by proper memory allocation practices, i.e. using the right allocator and not allocating memory like a chain smoker goes through cigarettes, but may nevertheless be a concern

- and as bioglaze said above, if your memory contains sensitive information, you would do well to get rid of that yourself rather than relying on the OS to do it (any modern OS will always wipe the contents of a newly allocated memory page per-process, so that a process doesn't see what an old process previously wrote somewhere in memory, but that might not happen for a while)

Also, if your destructor has observable side effects, then not calling delete may result in undefined behaviour (I'm not comfortable enough with C++ to tell whether it is for sure, maybe someone else can answer that, but you should probably check).

Memory may not be a problem, but there are other resources. For example, let's say that an object you didn't de-allocate maintains some kind of file handle (directly or indirectly). Many objects that do file I/O have an in-memory buffer. You might have written data to that buffer, but when the OS dismantles the process it has no idea that this memory is significant, and will discard it with the rest. The file handle will be closed, but the unwritten data is lost.

Operating system frees it, but does not necessarily overwrite it, so if you have passwords etc. in memory, you should overwrite them.

This incorrectly implies something which is very dangerous to believe, which is the assumption that clearing the memory yourself avoids this problem. _It does not_.

The OS is free to move the virtual pages around how it wishes, make copies of virtual pages, stream them out to disk, etc. If you have sensitive data, simply clearing it after use makes absolutely no guarantees that you've cleared all copies of it that might reside on RAM or even disk without your application's knowledge.

If you need security of anything in RAM, you must use mlock or VirtualLock or the like.

Note that GPUs are still evolving in this area and there aren't solid protections there yet for any data accessed via GPGPU APIs or graphics APIs. And don't forget that a malicious application can also often just trivially attach to your process as if it were a debugger and have full access to memory, syscall interception, and so on, assuming the OS doesn't just allow all processes of a particular user to read each others' memory (wasn't uncommon all that long ago). And then, if security is a serious concern, there's protections from peripheral devices (firmware hacks via driver bugs, USB dongles, etc.) that get mostly unfettered access to RAM (or even VRAM).

Even on mature operating systems, there are various system resources that are not automatically disposed of on program exit.

For example, semaphores and shared memory regions on Linux.

A mature OS will deallocate memory on exit of the application, which answers your question. But knowing that should just be a curious tidbit because whether or not memory is freed by the OS is not really that relevant or useful...

Cleaning up after yourself is about more than just deallocating memory, it's also about running destructors which themselves may have side-effects (freeing other kinds of resources, flushing buffers, saving state, etc).

It's also not something you should really need to worry about in modern C++ code since all heap allocated memory should be being auto-deallocated by a stack-bound RAII container. The delete keyword is effectively deprecated under normal use and relegated for use only for implementing RAII containers or for extenuated circumstances such as interfacing with legacy code/frameworks.