Information process and mapping

All variables, arrays, structures and unions that we worked with so far are statically allocated, meaning that whenever an appropriate scope is entered (e.g. a function is invoked) an amount of memory dependent on the data types and sizes is allocated from the stack area of the memory. When the program goes out of the scope (e.g. when a function returns), this memory is returned back to the stack. There is an alternative way of allocating memory, more precisely, from the heap part of the memory. In this case, the user makes specific calls to capture some amount of memory and continues to hold that memory unless it is explicitly (i.e., by distinguished calls) returned back to the heap. Such memory is said to be dynamically allocated.

In order to exemplify the usefulness of dynamic memory allocation, suppose that there are two types of foomatic collections: the first type refers to an array of ten integers, whereas the second type refers to an array of ten million integers. A foomatic chain is made from a combination of one million collections of first type and few (say, ten) collections of the second type. Such a chain demands a total memory capable of holding 110 million integers. Assuming that an integer is of size 32 bits, this amounts to a

memory of 440 Megabytes. A modern personal computer usually has enough memory to accommodate this data.

It is a foomatic convention to treat both types of collection uniformly, i.e., our plan is to represent both by a single data type. Think of the difference between you and me. I am the instructor (synonymously the president) of the class, whereas students are only listeners (synonymous with citizens). A president is the most important person in a society, he requires microphones, computers, bla bla bla. Still, both the president and each citizen are of the same data type called human.

So a foollection is a foomatic human capable of representing a collection of either type.

If we plan to handle it using a structure with an array (or union), we must prepare for the bigger collections. The definition goes like this:

typedef struct { int type;

int data[10000000];

} foollection;

Now irrespective of what a foollection data actually stores, it requires memory for ten million and one integers. (Think of each of you being given a PA system and a computer in the class.) A foomatic chain then requires over 40,000 Gigabytes of memory. This is

sheer waste of space, since only 440 Megabytes suffice. Moreover, no personal computer I have heard of comes with so much memory including hard disks.

What is the way out? Let us plan to redefine foollection in the following way:

typedef struct { int type;

int *data;

} foollection;

I have replaced the static array by a pointer. We will soon see that a pointer can be allocated memory from the heap and that the amount of memory to be allocated to each pointer can be specified during the execution of the program. Thus the data pointer in a foollection variable is assigned exactly as much memory as is needed. (It is as if when I come to the classroom, the run-time system gives me a PA system and a computer, whereas a student is given only a comfortable chair.) Now each collection requires, in addition to the actual data array, the space for an int variable and for a pointer, typically demanding 4 bytes each. So a foomatic chain requires a space overhead of slightly more than 8 Megabytes, i.e., a chain with all foomatic abstractions now fits in a memory of size less than 450 Megabytes. My computer has this much space.

Let me illustrate another situation where dynamic memory allocation proves to be extremely useful. Look at lists and trees made up of structures with self-referencing pointers:

Figure: Dynamic lists

A static array can implement such lists, but has two disadvantages:

• The size of a static array is fixed during declaration, i.e., a static array can handle lists of a bounded size. Even if my machine has more memory than yours, I cannot leverage this superiority of my computer with static arrays. On the other extreme, irrespective of the actual size of the collection, a static array necessarily consumes the entire space for the biggest supportable collection.

• The linked structure can be incorporated in the framework of an array, but that requires (often awful) calculations to find the locations of the next objects. If pointers with dynamically assigned memory are used, accessing objects following the links becomes much easier.

So there is a big bunch of reasons why we should jump for dynamic memory

management. Do it. But listen to the standard good advice from me. Dynamic memory allocation gives a programmer too much control of memory. Inexperienced programmers do not know how to effectively exploit that control. There remains every chance that everything gets repeatedly goofed up and the programmer, tired of fighting with segmentation faults for weeks, eventually gives up and joins the ice-cream industry. If you excel in this new job, I won't mind, even given that I am not a particular fan of creams. But my job is to teach you programming, not how to manufacture tasty ice-creams.