All about pointers: part 2

So now you learned pointers from part 1, right? What can we now do with them?

Well, we can use pointers in two ways:
1- As an abstraction over variables.
2- As just a memory location.

Abstraction over variables

Normal variables let us abstract over values; meaning "do something with x whatever value it has". Well, pointers let us store variables in variables, so to speak, and thus abstract over them.

For example, there is no pass by reference in C, but we can emulate it with pointers:

void readInt(int *x) {
cin >> *x;
}
main() {
int t;
readInt(&t);
}

The function main is passing the location &t (by value) to readInt. When readInt modifies *x, this means "go to the address stored in x, and in that address, store whatever comes from cin >>". This modifies the value of t; which is what we wanted.

This pass-by-value works for anything that has a memory location; not just simple variables:

main() {
Point p;
readInt(&(p.x));
}

This will take the address where p.x is stored, and pass it to readInt; so it will be the address where readInt will write.

Is there another use of 'abstraction over variables' other than pass by reference? Well, this depends on your imagination. We can do things like this:

void getAge( ) {
int x = 8;
dialog.scrollBox1.setBinding(&x);
showDialog( );
cout << x;
}

Here we can imagine the setBinding function storing a pointer to an integer (pointing to x in the example) and whenever the user slides the scroll bar, the content of the address stored in the pointer is changed. Therefore after the showDialog function ends we find the value of x automatically reflecting the scroll bar position. It is as if we passed the variable itself as an argument to the setBinding function.

Pointers as memory locations

We can also treat a pointer as just a location in memory, not associated with a named variable that already exists. This is helpful in situations like:

1- Dynamic memory.
2- Reading and writing buffers.
3- Accessing hardware devices.

Dynamic memory:

Local variables in functions are automatic variables; the size needed for each function's vars is calculated at compile time and space for all vars is allocated at function call, deallocated at function exit. This is useful for most programs but sometimes we want full control of memory allocation at runtime:
- Perhaps we have an array with non-fixed size.
- Perhaps we're using a linked list; where memory must be allocated only when we need to add to the list.
- Perhaps we're creating an interpreter for our own programming language, where the user's program will allocate memory.

In all cases, memory allocation takes a form like this
myPointer = malloc(memSize);
or
myPointer = new type;
or
myPointer = new type[numElements];

...and I can access the content of the pointer normally with *myPointer = xyz;

We are here using the pointer to store the address of a hypothetical variable that wasn't declared in the code. A 'run-time' variable if we may say. And since they need not be declared at compile time we can have as many of them as we wish and at the time we wish.

I think this has a theoretical aspect; and relates to theory of computation: think of turing machine and the infinite tape that gives them their computational power; and of finite state automatons and the finiteness of their states, as if they were 'compile time' memory :)

anyway...

Reading and writing buffers

Think of the fread function in C:

main() {
Point p1;
fread(&p1,myFile, sizeof(Point));
}

Here the fread function doesn't care if it's reading a point or not: all it needs is a memory location and the number of bytes to read, and it will fill that memory with data from the file. Here the pointer is treated purely as an address.

Accessing hardware devices.

In the good old days of DOS, you could do stuff like this:

// note: just a sample value
#define START_OF_VIDEO_MEMORY 0xA000

main() {
char *v = START_OF_VIDEO_MEMORY;
*(v + 5) = 60;
}

This would write the value 60 at five bytes after the start address of video memory. With code like this a developer could write directly to the video card; do tricks, make fast games....etc.

In modern operating systems this is impossible due to virtual memory. In a system like 32-bit Windows each program sees memory as 4GB all of it available to itself. The operating system does a lot of work to keep programs from taking each others' memory and keep each program thinking it owns all memory on the machine. This means that the address 0xA000 no longer means anything special; it's just a part of the virtual address space that could be valid or invalid for the running process (if it's valid, writing to it will change some unknown part of your program; if invalid your program will crash).

This leads to things like DirectX...etc to make game programming faster on Windows; but does that mean pointers for direct access are no longer useful?

Well, sometimes they're still useful. For example some hardware devices (sensors, robot controllers...) will take the virtual memory system to their advantage; the device's driver will map some memory on the device itself to memory in your program! This means you can use pointers to read or write directly to the device memory. It usually goes like this:

#include "sensor.h"
main() {
char * p = sensor_map_memory( "mySensorDeviceName");
// do what you want with p...
sensor_unmap_memory(p);
}

We've taken a nice journey now, and saw why C has a reputation for being suitable for low-level code; took a look into abstraction and dynamic memory, and hopefully understood pointers at a deeper level. I hope you liked the article!