释放动态分配的内存

Question

In C++, when you make a new variable on the heap like this:

int* a = new int;

you can tell C++ to reclaim the memory by using delete like this:

delete a;

However, when your program closes, does it automatically free the memory that was allocated with new?

Answer 1

Yes, it is automatically reclaimed, but if you intend to write a huge program that makes use of the heap extensively and not call delete anywhere, you are bound to run out of heap memory quickly, which will crash your program.

Therefore, it is a must to carefully manage your memory and free dynamically allocated data with a matching delete for every new (or delete [] if using new [] ), as soon as you no longer require the said variable.

Answer 2

When the process is terminated the memory is reclaimed back by the OS. Of course this argument shouldn't in any case be used to not perform proper memory management by the program.

Answer 3

Don't let people tell you yes. C++ has no concept of an OS, so to say "yes the OS will clean it up" is no longer talking about C++ but about C++ running on some environment, which may not be yours.

That is, if you dynamically allocate something but never free it you've leaked. It can only end its lifetime once you call delete / delete[] on it. On some OS's (and almost all desktop OS's), memory will be reclaimed (so other programs may use it.) But memory is not the same as resource! The OS can free all the memory it wants, if you have some socket connection to close, some file to finish writing to, etc, the OS might not do it. It's important not to let resources leak. I've heard of some embedded platforms that won't even reclaim the memory you've not freed, resulting in a leak until the platform is reset.

Instead of dynamically allocating things raw (meaning you're the one that has to explicitly delete it), wrap them into automatically allocated (stack allocated) containers; not doing so is considered bad practice, and makes your code extremely messy.

So don't use new T[N] , use std::vector<T> v(N); . The latter won't let a resource leak occur. Don't use new T; , use smart_ptr p(new T); . The smart pointer will track the object and delete it when it's know longer used. This is called Scope-bound Resource Management (SBRM, also known as the dumber name Resource-Acquisition is Initialization, or RAII.)

Note there is no single " smart_ptr ". You have to pick which one is best. The current standard includes std::auto_ptr , but it's quite unwieldy. (It cannot be used in standard containers.) Your best bet is to use the smart pointers part of Boost, or TR1 if your compiler supports it. Then you get shared_ptr , arguably the most useful smart pointer, but there are many others.

If every pointer to dynamically allocated memory is in an object that will destruct (ie, not another object that is dynamically allocated), and that object knows to free the memory, that pointer is guaranteed to be freed. This question shouldn't even be a problem, since you should never be in a position to leak.

Answer 4

No, it's your responsibility to free it. Also, a must be a pointer, so it should be:

int *a = new int;
delete a;

This excellent answer by Brian R. Bondy details why it's good practice to free the memory allocated by a .

It is important to explicitly call delete because you may have some code in the destructor that you want to execute. Like maybe writing some data to a log file. If you let the OS free your memory for you, your code in your destructor will not be executed.

Most operating systems will deallocate the memory when your program ends. But it is good practice to deallocate it yourself and like I said above the OS won't call your destructor.

As for calling delete in general, yes you always want to call delete, or else you will have a memory leak in your program, which will lead to new allocations failing.

Answer 5

No, when the program exits ("closes") the dynamically allocated memory is left as is

EDIT:

Reading the other answers, I should be more precise. The destructors of dynamically allocated objects will not run but the memory will be reclaimed anyway by any decent OS.

PS: The first line should read

int* a = new int;

Answer 6

When your process terminates, the OS does regain control of all resources the process was using, including memory. However, that, of course, will not cause C++'s destructors to be necessarily run, so it's not a panacea for not explicitly freeing said resources (though it won't be a problem for int or other types with noop dtors, of course;-).