Why do you need to allocate memory in c/c++?

Question

Getting straight to the point: What is the reason for needing to allocate memory in c++?

I understand some programming languages do it automatically, but in C/C++: what is the reason for having to allocate memory. For example: When declaring PROCESSENTRY32, why do we need to ZeroMemory() it? When making a buffer for a sockets program, why do we need to ZeroMemory() it? Why don't you need to allocate memory when you declare an int data type?

Answer 1

C chooses to be relatively low-level language where language constructs more or less directly map to at most a few machine instructions.

Block level allocations such as in

int main()
{
   int a,b,c; //a very cheap allocation on the stack
   //... do something with a, b, and c
}

fall within this category as all block-level allocations together in a function will normally translate to just a single subtraction to the stack pointer.

The downside of these allocations is that they're very limited -- you shouldn't allocate big objects or multiple objects like this (or you risk stack overflow) and they're not very persistent either--they're effectively undone at the end of the scope.

As for generic allocations from main memory, the machine doesn't really offer you much apart from a big array of char (i.e., your RAM) and possibly some virtual memory mapping facilities (i.e., mapping real memory into smaller arrays of char). There are multiple ways for slicing up these arrays and for using and reusing the pieces, so C leaves this to the libraries. C++ takes after C.

Answer 2

Your question doesn't really make sense. ZeroMemory doesn't allocate memory; it just, well, sets bytes to 0. You can easily ZeroMemory an int, if you want. It's just that i = 0; is shorter to write.

In all cases ZeroMemory only works on memory that already exists; i.e. something else must have allocated it before.

As for actual allocation, C distinguishes three kinds of storage for objects:

1. Static storage. These objects are allocated when the program starts and live for as long as the program runs. Example: Global variables.

2. Automatic storage. These objects are allocated when execution reaches their scope and deallocated when execution leaves their containing scope. Example: Local variables.

3. Dynamic storage. This is what you manage manually by calling malloc / calloc / realloc / free.

The only case where you really have to allocate memory yourself is case #3. If your program only uses automatic storage, you don't have to do anything special.

In languages like Java, you still have to allocate memory by calling new. Python doesn't have new, but e.g. whenever you execute something like [...] or {...}, it creates a new list/dictionary, which allocates memory. The crucial part is really that you don't have to deallocate memory.

Languages like Java or Python include a garbage collector: You create objects, but the language takes care of cleaning up behind you. When an object is no longer needed¹, it is deallocated automatically.

C doesn't do that. The reasons lie in its history: C was invented as a replacement for assembler code, in order to make porting Unix to a new computer easier. Automatic garbage collection requires a runtime system, which adds complexity and can have performance issues (even modern garbage collectors sometimes pause the whole program in order to reclaim memory, which is undesirable, and C was created back in 1972).

Not having a garbage collector makes C

• easier to implement
• easier to predict
• potentially more efficient
• able to run on very limited hardware

C++ was meant to be a "better C", targeting the same kind of audience. That's why C++ kept nearly all of C's features, even those that are very unfriendly to automatic garbage collection.

---

¹ Not strictly true. Memory is reclaimed when it is no longer reachable. If the program can still reach an object somehow, it will be kept alive even if it's not really needed anymore (see also: Space leak).