1

I'm new to C++ and I just learned that when creating a new'ed pointer to heap memory, you have to delete it manually, for example:

int *a = new int;
...
delete a;

But, what if I don't delete it? Will it still take space on the heap forever (not literally forever, but you get the idea). I've created a few projects where I was just testing and messing around with it, and in some cases I didn't delete the pointer afterward. So, does it get delete'd automatically by Visual Studio (which I'm using)? Or, is it too late now and I can't do anything about it (freeing that space somehow)? Also, should I be worried (because I am)?

Remy Lebeau
  • 454,445
  • 28
  • 366
  • 620
VoId
  • 119
  • 6
  • 2
    More practical example. You reach into a cabinet of tools and take a tool. There is one less tool in the cabinet. If you keep taking taking tools and never put them back sooner or later you will reach for a tool and not have one. If you stop needing tools before you run out, likely you never notice. – user4581301 Apr 02 '20 at 22:18
  • The object continues to exist as long as your program runs, which is a waste of memory. – HolyBlackCat Apr 02 '20 at 22:19
  • 3
    You should avoid `new`/`delete` when possible, exactly because it's easy to forget to delete objects. Prefer containers and smart pointers. – HolyBlackCat Apr 02 '20 at 22:20
  • Handy reading on the point HolyBlackCat just brought up: [Why should C++ programmers minimize use of 'new'?](https://stackoverflow.com/questions/6500313/why-should-c-programmers-minimize-use-of-new) – user4581301 Apr 02 '20 at 22:22
  • "_will it still take space in the heap for ever (not literally for ever but you get the idea)_" If your program runs for ever, that space will not be freed, literally, for ever. – Algirdas Preidžius Apr 02 '20 at 22:34
  • Do this and see what happens while(true) { int* a = new int; } – Omid CompSCI Apr 03 '20 at 00:34
  • If your memory leak is not too large, your program could run for a long time, slowly growing, and the OS will happily swap out unused pages (unless you oscillate new's that you forget, and new's that you continue to touch periodically). valgrind. – ChuckCottrill Apr 03 '20 at 01:40

1 Answers1

3

After a program terminates, the memory is freed by the operating system. The year is 2020, so there is no harm in those test applications you had since all modern operating systems handle it.

That said, while the program was running, that memory remained allocated. This is bad because you are no longer using that memory and it is a waste of resources.

nowi
  • 357
  • 2
  • 12
  • an example of where it might matter on modern systems: when you unload a Windows DLL from a process, the memory is not reclaimed. So a leaky DLL continually loaded and unloaded will grow over time . I had this issue with OpenSSL which used malloc on global pointers that it never freed.. did submit a patch but had it rejected by OS partisans – M.M Apr 02 '20 at 23:57
  • This is a good example but to clarify: the program has not terminated, only a library was unloaded. Regardless, freeing memory is extremely important. – nowi Apr 02 '20 at 23:58
  • @M.M that is because OpenSSL was never meant to be loaded/unloaded multiple times during a process's lifetime, so the authors didn't originally design safely into its global allocations, and it took a long time for them to provide necessary cleanup routines that could be called on-demand. This is a bit better in OpenSSL 1.1.x, but the issue still exists to some extent. – Remy Lebeau Apr 03 '20 at 00:16
  • @RemyLebeau yeah - the devs in control of the project didn't know and/or didn't care about that use case. It happened to me with an in-process COM server authored with C++B; the DLL got unloaded when the last active object was released . Can be worked around of course, once the problem is realized . – M.M Apr 03 '20 at 00:20
  • There is no harm in small "test applications", hosted by a modern operating system, forgetting to release memory resources. Except ..... a lot of "test applications" are actually reused. I've been involved in auditing significant projects, and lost count of the amount of such reused "toy" code that has become the root cause of memory leaks and other problems in larger systems, including in a couple of device drivers (installed on modern operating systems). Frankly, programmers cannot be trusted to not reuse such code, nor can they be trusted to clean up the leakages when they do. – Peter Apr 03 '20 at 01:11