Short answer: yes, the OS will free this memory.

Most operating systems will free this memory, however it is bad practice to rely upon this behaviour. Some operating systems will not free this memory. For example, embedded systems. For portability, always free all the memory you allocate.

大部分現代作業系統都會釋放，但這是個壞習慣。有些作業系統不會，例如嵌入式系統。 C/C++ doesn't have garbage collection feature. If you allocate memory and doesn't free it up, it's of no use while the program execution continues. This is called memory leak. Once the execution finishes, OS takes back this memory and is again available for use.
C/C++沒有垃圾回收機制。如果你不釋放，程式繼續執行時，記憶體不可用，這就叫記憶體洩露。一旦執行結束，作業系統會回收，這個記憶體又可以被使用了。

During the program's execution, you cannot count on the operating reclaiming the memory. That would be a garbage collection feature found in many other languages such as Java and C#. While garbage collected c++ is possible, I don't believe any mainstream implementations use it.

On the other hand, once your program completes its execution, the OS should reclaim the memory used by the program. So during execution the memory remains off-limits, but is accessible again after the program exits.

java和C#有垃圾回收機制。 Modern OSes reclaim all resources of a closed process. Not only memory, but also file handles, etc.
現代作業系統回收關閉程序的所有欄位，不僅記憶體，還有檔案控制代碼等。

No fear, the OS reclaims all the memory. What you need to watch out for is leaving some persistent resources, such as files, in an indeterminate state.

Just FYI my programming language deliberately fails to free memory on exit by default: it's faster that way. However RAII is not permitted. In C++ if you use RAII then you need to take more care.

不必擔心，會回收記憶體。你需要觀察，是否遺留了長期資源，比如檔案，在不可知狀態。

Fast answer is no damage for OS if program don't call destructors of created objects or not freeing memory or other OS handles. Maximum impact is lost part of files which program has written before exiting.

Therefore Herb Satter in their book write about technique that short-lived applications specially doesn't free memory and don't call destructors for maximum speed of execution.

But better that programs normally handles their used OS resources.

最需要關注的是，程式退出時，檔案內容的丟失。

On a modern multiprocessing OS that uses Virtual Memory (eg: Windows 7, Linux), it is true that all (OK, not all, but let's not be nit-picky here) resources are process-specific and will be released back to the system when the process terminates.

So does it matter if your program "leaks memory"? Well, that depends on how it does it.

If you allocate a bunch of resources at startup, no it does not really matter if you manually free them at shutdown or just let the OS do it. I'll admit to being a lazy programmer who likes to let the OS handle such things.

However, if you allocate resources in a loop or on demand at runtime for some reason, and don't bother to manage them in some way, then theoretically if you let your program run long enough it will continually "leak" resources until the point comes that there aren't any more left to allocate. This is aBad Thing. Don't do it.

Now there are a lot of platforms that do not behave this way. If you ever end up doing embedded work, you are quite likely to end up on a platform where you have to manage all of your own resources (manually free memory, close file handles, etc.)

現代多程序作業系統，使用虛擬記憶體。幾乎所有的資源是程序相關的，當程序結束時則資源釋放。 但是如果你在迴圈中不停的申請資源而不釋放，到達了極限，則會引發問題。 有些系統不會自動回收資源，例如嵌入式開發。 所以，養成申請、釋放記憶體、控制代碼，肯定是個好習慣。