University of Virginia, Department of Computer Science
CS655: Programming Languages
Spring 2000

Position Paper 2
Yves LEPOUCHARD
21 February 1999

An Array of Arrays


I have selected FORTRAN and C. By FORTRAN, I refer to FORTRAN IV. In this version of FORTRAN, only arrays of up to three dimensions are possible and they have to be declared explicitly like in the following example:

DIMENSION ALPHA(10,15)

where ALPHA is a 2-dimension array. The dimensions of an array as specified in a DIMENSION statement must be numeric. The use of an array is limited by strict rules. For example, a variable that represents the name of an array may not be used without subscripts in a FORTRAN program (except under very specific circumstances). These subscripts themselves meet other rules.

In C, arrays also have to be declared explicitly like in:

int alpha[10][15];

The exact limit of dimensions, if any, is determined by the compiler. C allows a little more flexibility by enabling constant variables or macros to define the size of arrays. However, the principle of defining the storage allocated to the data structure remains the same. The difference between C and FORTRAN is that C arrays are closely related to pointers. In the example:

int p[23];

p is a pointer to the first element of the array. Pointers are an important and powerful feature of C and their close relationship with arrays is very convenient. In the following example, the two last lines are equivalent:

char str_array[30][80];
gets(str_array[2]);
gets(&str_array[2][0]);

gets is a procedure. Its parameter is a string which is an array of characters. str_array is an array of strings and str_array[2] is a pointer to the first character of the third string of the array. & is an operator which passes the address of a variable. So &str_array[2][0] is the address of the first character of the third string of the array.

The following example shows how to assign a value to an array in different ways:

p[5] = 10;
*(p+5) = 10;

The two lines are equivalent. The first one is more "array-oriented" when the second one just considers p as pointer. Therefore p+5 is a pointer too and *(p+5) is the element pointed by it. This flexibility enables to treat problems under different approaches and is a real asset of C.

Clearly the two programming languages compared in this paper have neither the same history nor the same spirit. FORTRAN is one of the oldest programming languages (its implementation has started in the fifties) and is still widespread in industry. It has been designed to be able to program machines in a very pragmatic way. C is much more recent and is more related to the boom of personal computers. Its generality and an absence of restrictions make it more convenient and effective for many tasks. It is based more on a community than on industry. The convenience of C is clearly the product of several decades of experience in the design of programming languages when FORTRAN plays the role of ancestor.

However, pointers provide a powerful feature to manage data by allowing for example the easy generation of dynamic lists storing an amount of data which is unknown before run-time. FORTRAN should have some hard time to implement such a function. The very elegant way C manages strings cannot be compared with FORTRAN which even does not allow the use of characters. Under these circumstances, it is very hard to find an array mechanism which is better implemented in C or in FORTRAN. I think FORTRAN provides sufficient array mechanisms for its precise functions but does not have as many featutes as C arrays. The superiority of C, even though apparent through arrays, resides in more fundamental levels of its design.

If one wanted to introduce these features in FORTRAN, both pointers and characters should be provided by this language. Such an alteration of the language structure could change its whole idea. Pointers could introduce bugs and errors if badly used by programmers in a language known for its robustness. The administrators and developers of critical systems using FORTRAN could then consider it too risky. Thus trading security for flexibility would not be a good idea.


CS 655 University of Virginia
CS 655: Programming Languages
yel4j@cs.virginia.edu