Sections 0101, 0102, 0103 and Honors, Fall 1995
Tuesday November 28, 1995
Assigned Reading: 13.3 - 13.4
Handouts (available on-line): none
Topics Covered:
- Attendance was taken.
-
We continued looking at the swap function which exchanges
the contents of two variables. In the second version of this
function, we print out the addresses of the variables. Second program and sample run. In the
next version of the program, we deliberately forget to use a
function prototype for the swap_integers function. Then,
if we mistakenly pass the values of the variables a and
b, executing the program will cause a core dump. If the
prototype were in place, the compiler would have caught the
error. Program and sample run.
- A word of warning: a function should never return the
address of a local variable to the function that called it.
This could cause all sorts of problems as the next
example shows. Program and sample run.
- We can also use pointers to point to arrays.
In the our first example, we explicitly assign the address of an
array to a pointer. This allows us to access items in the
array using pointer dereferencing.
See program and
sample run.
-
In the next program,
the array parameter A is really a pointer to the elements of
an array. (See sample run.)
Note that we can use A to retrieve the
elements of the array in two ways: using pointer dereferencing
*A and using array notation A[i].
For example, the first element of the array
can be accessed by deferencing A using the
expression *A or by the array element notation
A[0]. Thus, array parameters are really pointers!
- However, there is a difference between pointers and arrays.
When an integer pointer is declared, the compiler sets aside
4 bytes of memory to hold an address. When an integer array,
say with 10 elements, is declared the compiler sets aside
40 bytes of memory to hold 10 integers. We can have a pointer
hold the address of an array, but this does not set aside
any memory to hold the array. Also, we cannot assign the
address of an array to another array, this would be
a syntax error: program and
sample run.
- Another word of warning: you are allowed to add constants to
a pointer, but the result may not be what you think. The following
example shows that adding 1 to a character pointer, an integer pointer
and a double pointer, adds 1, 4 and 8 respectively to the addresses
stored in the pointers.
Program and sample run.
- We can set aside (or allocate) memory dynamically
(when the program is executed, not when it is compiled) by calling
the malloc function. This function returns the address
of the array which should be stored in a pointer variable. The
amount of memory allocated for the array is given as the actual
argument when the malloc function is called.
- Our first example using malloc requests 26 bytes
to store an array of characters. We can use this array to hold
the letters of the alphabet.
Note that malloc returns
a pointer value, but elements of the array can be accessed
using array notation. Also, when we are done with the block
of memory allocated by malloc we should free it using
the function free.
See Program and
sample run.
- Our second program using memory allocation calls malloc
to allocate an array of integers. We use the casting operator
(int *) to change the type of the value returned
by malloc from pointer to void to pointer
to int. We also check to see if malloc
successfully allocated the requested amount of space.
(If malloc failed, it returns the NULL value
which is defined to be zero in stdio.h.)
In this program, the size of the array depends on a value
entered by the user. Here we see that malloc allows
us to dynamically change the number of elements in an array.
Something that static arrays cannot achieve. If the user
enters 10, then we should request 40 bytes of memory, because each
integer takes 4 bytes and we want an array of 10 integers. Since
a different compiler might use a different number of bytes to
store an integer, we arrive at the number 40 by multiplying 10 to
sizeof(int). This way, our code is more portable.
See Program and
sample run.
Last Modified:
Fri Dec 1 16:01:11 EST 1995
Richard Chang, chang@gl.umbc.edu