[CALL FOR AUTHORS: I am considering expanding this book to include more languages, and maybe even how memory management is implemented for cellphones and 64-bit computing. If you are interesting in expanding this book (for a future self-published book) email me at mdaconta 'at' oberonassociates.com or mdaconta 'at' aol.com (email address spelled out to avoid spam robots).]
For previous sections, click here.
CHAPTER 1 - An intuitive approach
OBJECTIVE: An intuitive understanding of pointers through an analogy to storage containers.
A pointer can be defined as a memory location that stores the address of another memory location; however, this definition is dependent upon the reader knowing the meaning of memory location and address. Let's first get an intuitive picture:
Figure 1.1 A pointer as a container
Visualization is a good method to remember concepts. That is just what we need with pointers - a good mental image of what is going on inside the computer! A simple way to visualize a memory location is as a container and therefore a computers entire memory would be a long row of containers. A container is a good analogy for a memory location because they both can store things. Each container has a unique number on it so that the computer can access any container in the same amount of time. This is why computer memory is called Random Access Memory or RAM. The CPU can access all memory locations in the same amount of time by putting the address of the desired memory location on the address bus. Remember, the address is that unique number that identifies each piece of memory. Each memory location is numbered sequentially starting from 0. Another common analogy for computer memory is rows of houses. A house can store things and you locate a specific house by its address.
Figure 1.2 Memory as a row of containers
Continuing with our container analogy, another definition of a pointer would be a container that stores the unique number of another container! So, here we have non-technical (but functional) definitions for memory location, address and pointer:
Memory Location - a container that can store a binary number.
Address - a unique binary number assigned to every memory location. The size of the addressable space depends on the number of data lines in the address bus.
Pointer - a memory location that stores an address.
The above intuitive explanation of pointers answers the question "what is a pointer?" but does NOT answer "how does a memory location store a binary number?" or "how can a computer use an address to access a memory location?" The answers to these questions are good for general knowledge but not critical to our discussions of pointers. The interested reader will find the two questions answered in Appendix A.
Let's look at a practical example of code that demonstrates our general concept:
/* pointer_intro.c */
/* declare a pointer variable to hold an address of an integer. Do not worry about understanding the exact syntax, we will cover this in more detail in chapter 3. */
/* declare an integer variable. This is a container that holds an integer. */
/* assign an integer to the variable "my_int" */
myint = 10;
/* print out the address of the integer. This is the unique memory location where the integer is stored. */
printf("the address of myint is %p.\n",&myint);
/* Remember that a pointer can store the address of another container. This means that we can put the address of the integer myint into out integer pointer. */
integer_pointer = &myint;
printf("the integer_pointer holds the address %p.\n",integer_pointer);
Here is a run of the above program:
the address of myint is 003E200E.
the integer_pointer holds the address 003E200E.
1. Why is a container a good analogy for a memory location?
2. Why is it necessary for each container to have a unique number on it?
[Note2: Do you have good answers to these questions? Do you have any additional questions on these concepts?? If so, email me!! ]
[Note3: You should notice how the graphics were updated from the original of this book. I had to redo them as I don't even have the original macintosh files for the book. This book was written in 1993 so that should say it all. :) ]