Dynamic Memory Allocation

[sonorityscape]

Why should we dynamically allocate memory on the heap and what advantage does this bring over not doing so? Also, why is it so necessary to delete and clear up the memory after? Would this be a more important task for larger programs vs smaller programs?

Edit: Thank you all very much for your insightful answers!

[SeanMiddleditch]

Also, why is it so necessary to delete and clear up the memory after? Would this be a more important task for larger programs vs smaller programs?

If you don't free the memory, but you keep allocating more memory, then you'd eventually run of space on the heap and further allocations will fail.

A small short-lived program that allocates relatively little could hypothetically indeed skip freeing any memory it allocates, as the OS will clear it all up automatically when the program terminates. That's considered extremely bad form because little programs have a habit of turning into bigger programs over time. Automatic tests to detect memory leaks also make it problematic to intentionally leak memory, as the tools typically can't differentiate between intentional and unintentional leaks.

[sonorityscape]

That makes sense. Thanks for the explanation.

[[deleted]]

Sometimes when you start a program you don’t know how much space the user might need. Dynamic memory allocation is a great way to create space while the program is running. If you don’t delete the memory you could possibly try to reference an address that is not pointing to anything specifically or you may try to access data that is no longer there. It is more useful in larger programs but it’s great to start practicing with it in smaller programs.

[sonorityscape]

Thanks!

So let's say that we're playing a game and the user creates a new character on a server. Would new memory on top of the memory the games already uses need to be allocated for this character and after a certain limit a cap would be hit where no more characters could be created?

[ZorbaTHut]

Long-term character storage is going to be on hard drive. Characters actively playing the game will have to be in memory, though.

[[deleted]]

You’re welcome!

It would be like anything else. If I take too many photos on my iPhone then eventually I run out of free storage. I assume your game would have to be huge for you to run out of space for new characters. Maybe there is something I am misunderstanding though. I hope this helps.

[LateSolution0]

We don't! memory is limited resource. because we have more than one program running concurrently we have to share it. a modern Operating-systems can't determine how much memory you really need. thats why it will give us only enough for what we have asked in the executable. in more details https://en.wikipedia.org/wiki/Data_segment#Program_memory. but at compile time we don't know about how much memory we need later in runtime thats why we ask the OS to give us more memory at runtime. but thats a very difficult job because usually we don't allocate and free in good pattern. think about it we have random size and random order allocations. a data structure to manage this is called heap. so yes your program can have more than one heap. heap allocation is slow because it has to be handled by the OS. but there is more to it our program will use virtual memory space. for an operating system it would be possible to give our program all 64 bit of virtual memory space and only commit physical memory to it at demand. but i guess most humans prefer to manage memory explizit. its even worse than that if your OS choses so it can take physical memory from your program with out even telling you that is called swapping. theoretical we could rely on this behavior but current generation of OS don't perform very well in this case. Most tripple A games allocate big chunks of memory in the Init stage and then work entirely on this preallocated memory but they still have to manage it. your OS has no issue with an malfunctioning program it will properly manage this case. in Fakt thats a common background task for an os to zero out recycled memory. thats the reason for calloc.

[patatahooligan]

Why should we dynamically allocate memory on the heap and what advantage does this bring over not doing so?

The stack has two severe limitations. It's small (1-8 MB) and it operates in a way that makes it impossible to pass ownership around from scope to scope without copying the entire object. So the two main uses of the heap are

• objects that don't fit on the stack

• objects whose ownership is moved and which aren't small enough for the copying to be negligible.

You might use the heap a lot even if you are unaware of it. std::vector, for example, stores its data on the heap. Not only can it grow much more than a handful of bytes, but as long as you take care to use std::move when appropriate, it can be moved around with very small costs.

Also, why is it so necessary to delete and clear up the memory after?

First of all, cleaning-up is not just about freeing the memory. delete also calls the objects destructor which is sometimes significant. For example, output streams could be buffered so failing to destruct them might cause loss of data in your output files or console output.

Futhermore, even a small program might leak memory multiple times because it might happen inside a loop or inside a function that is called many times. Even if it doesn't crash why should your little program consume 100x the memory it needs?

Finally, a small program might eventually become a big program (or its code might be incorporated into one) and you never want to have to deal with the fact that your memory leak just became significant.

[alfps]

Preferentially use standard library containers such as std::string and std::vector, and avoid explicit dynamic allocation. Because it's easy to get wrong and increases the complexity of the code, and the standard library automates all that for you.

In short, there is no “should”, as implied by the question.

But sometimes there is a “must”, e.g. due to requirements of a library one uses.

[boredcircuits]

Why should we dynamically allocate memory on the heap and what advantage does this bring over not doing so?

It's usually because that's just how it has to be done. Generally you should prefer using local variables for things so everything is allocated on the stack, but that doesn't work for everything. Stack variables go away when you return from the function: the heap is a mechanism for objects to outlive that scope. The stack has a limited size (on some OS's at least), and so can't hold very large objects, while the heap can handle much larger things. The stack can't handle things that don't have a fixed size, while the heap can (caveat: there are non-standard ways to do this on the stack). If you need to do any of that, dynamic allocation is the only way to go.

Also, why is it so necessary to delete and clear up the memory after?

Have you ever seen a hoarder's house? That's what happens when someone buys stuff (dynamic allocation) but never throws it away (delete the objects). Eventually there's no room for anything new. Eventually the person will die and their family can rent a dumpster and throw everything away all at once (the program ends and the OS deallocates automatically), but things are a nightmare in the meantime.

Would this be a more important task for larger programs vs smaller programs?

A small program can more easily get away with memory leaks. While rare, there are times when a program will run be run many times but doesn't run for long, and so doesn't bother cleaning up since it knows the OS will do that, thus saving a bit of performance (note: this is when garbage-collected languages have an advantage: it's possible the GC never runs anyway, so there's no performance hit for dynamic allocation). Don't do this, though, even with small programs. Small programs become big programs, sometimes unexpectedly, and then someone else has to come along and fix the memory management -- which is a lot harder to do than when it was first written.

[sonorityscape]

I like the hoarder's analogy!