Why C is not a good numerical language

The religious war between C and FORTRAN lovers is an old one, and those of us supporting FORTRAN are often accused of living in an era somewhere between the 1960's and the age of the dinosaurs. Although I do write code in both C and FORTRAN, and even write numerical code in C, this page highlights some of the issues of which good C programmers should be aware.

Naturally, there is nothing wrong with writing in C if most of the time is spent in library calls, if the code is a messy heap of integer fiddling, or if the code is designed for a processor where optimisation is trivial. Even C++ is reasonable if its sophisticated data types add significant amounts of clarity to the code.

The Problem

A compiler's job is to produce correct, optimised code corresponding to the source offered to it. The C language has been called `device independent assembler', and, indeed, it does map fairly directly onto the sort of operations that microprocessors of the 1970s performed. It is a general-purpose language.

FORTRAN, or FORmula TRANslation, owes as much to the language of simple algebra as to machine code, and its stricter, more precise syntax makes the compiler's job of optimisation for `exotic' architectures (SMP, vector, preloading) very much easier. It is not that C compilers are less good: they cannot be as good.

This all matters little if one's target processor is a single late 1990's RISC processor, or one of the IA32 line. But then, with such modest aims, one is hardly concerned with serious numerical work.

The comments against C apply equally to C++. One could readily write a critique of FORTRAN90 too, but I have not yet had the time...

2019 Update

The above pages were mostly written over two decades ago (they are slightly older than the copyright statement suggests). Now there is less use of C, more of C++ and python, and Fortran is evolving too. One new issue has arisen from modern hardware: vectorisation. So I add: