I posted a program earlier today in response to another thread and noticed that I had forgotten to clean up/free the memory I used. Here's the program.

#include <iostream>

using namespace std;


int main()
{
    int LIST_SIZE, NUM_CHARS_PER_ELEMENT;
    cout << "Enter number of elements in list: ";
    cin >> LIST_SIZE;
    cout << "Enter number of characters in each array element: ";
    cin >> NUM_CHARS_PER_ELEMENT;
    
    char **list = new char*[LIST_SIZE];
    for (int i = 0; i < LIST_SIZE; i++) 
    {
        list[i] = new char[NUM_CHARS_PER_ELEMENT];
    }
    
    cout << "Enter " << LIST_SIZE << " names\n";
    for (int i = 0; i < LIST_SIZE; i++)
    {
        cout << "Enter name " << i << " : ";
        cin >> list[i];
    }
    
    cout << "Here are the names\n";
    for (int i = 0; i < LIST_SIZE; i++)
    {
        cout << "Name " << i << " : " << list[i] << endl;
    }
    
    for (int i = 0; i < LIST_SIZE; i++)
        delete []list[i];
        
    delete list;

    return 0;
}

I left off lines 33 through 36 in my prior post. My question is this. Are lines 33 - 36 necessary? What happens if I leave them out? Our instructors drilled into our heads the need to free any memory we reserved with new once we were done with it, but in this case, since this is done at the very end of the program, does it really matter? Isn't the memory released automatically when the program ends?

Recommended Answers

All 7 Replies

Technically each memory you allocated has a hidden header and has been tagged and associated with your application. When it shuts down the memory allocated will be released back to the pool.

In reality, you MUST ALWAYS release any memory you allocate, just to be a proper (PROFESSIONALLY WRITTEN) application.

Don't get lazy and rely on the system to do your chores!

Isn't the memory released automatically when the program ends?

Yes and no. It depends on how your OS handles processes, but unless you work with some obscure or legacy systems, it is pretty safe to assume that when the program ends, all heap memory allocated to the process is freed by the OS.

The real danger of not freeing your own memory is if your code is reused in something longer lived. I've seen a lot of one off programs get hoisted into a library, and if those programs did not free their memory, they could have killed the hosting program by leaking away memory until a crash or freeze.

Good answers. Thank you. Basically, it sounds like it boils down to "Even if it isn't necessary, do it anyway to be safe."

I'll leave this unsolved for now in case anyone has anything more to add. Again, thanks for the responses so far.

Your question is completely dependent on the fact as to "How type safe is the language we are using?" Languages which assure complete type safety assure the release of memory at the end by the process of "Garbage Collection".
Even though C++ is a type safe language it entertains several features of C language just for the sake of backward compatibility and this is what prevents us from developing an effective Garbage Collector for C++ because an effective garbage collection is possible only in case of complete type safe languages and C++ doesn't reach the 100% mark.
It further depends on how your OS is as some take specific care about every memory allocated even if its in a type unsafe language.

So with all these things in mind its always better not to rely on the inbuilt Garbage collector provided by the language or by the OS and free the memory ourselves.

If you're working with Visual Studio on Windows, the following is a handy library.

Put this at the top of your file.

#ifndef NDEBUG
#include <crtdbg.h>
#endif

Insert the following just before your code exit.

#ifndef NDEBUG
	_CrtDumpMemoryLeaks( );
#endif

Note that this will 'find' leaks from allocations that occur in one-shot (static) classes. But it'll alert you to memory leaks!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.