Introduction

page 2

Deep sentence:

...C deals with the same sort of objects that most computers do, namely characters, numbers, and addresses.

C is sometimes referred to as a ``high-level assembly language.'' Some people think that's an insult, but it's actually a deliberate and significant aspect of the language. If you have programmed in assembly language, you'll probably find C very natural and comfortable (although if you continue to focus too heavily on machine-level details, you'll probably end up with unnecessarily nonportable programs). If you haven't programmed in assembly language, you may be frustrated by C's lack of certain higher-level features. In either case, you should understand why C was designed this way: so that seemingly-simple constructions expressed in C would not expand to arbitrarily expensive (in time or space) machine language constructions when compiled. If you write a C program simply and succinctly, it is likely to result in a succinct, efficient machine language executable. If you find that the executable resulting from a C program is not efficient, it's probably because of something silly you did, not because of something the compiler did behind your back which you have no control over. In any case, there's no point in complaining about C's low-level flavor: C is what it is.

Next we see a more detailed list of the things that are not ``part of C.'' It's good to understand exactly what we mean by this. When we say that the C language proper does not do things like memory allocation or I/O, or even string manipulation, we obviously do not mean that there is no way to do these things in C. In fact, the usual functions for doing these things are specified by the ANSI C Standard with as much rigor as is the core language itself.

The fact that things like memory allocation and I/O are done through function calls has three implications:

1. the function calls to do memory allocation, I/O, etc. are no different from any other function calls;

2. the functions which do memory allocation, I/O, etc. do not know any more about the data they're acting on than ordinary functions do (we'll have more to say about this later); and

3. if you have specialized needs, you can do nonstandard memory allocation or I/O whenever you wish, by using your own functions and ignoring the standard ones provided.

The sentence that says ``Most C implementations have included a reasonably standard collection of such functions'' is historical; today, all implementations conforming to the ANSI C Standard have a very standard collection.

page 3

Deep sentence:

...C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly.

This aspect of C is very widely criticized; it is also used (justifiably) to argue that C is not a good teaching language. C aficionados love this aspect of C because it means that C does not try to protect them from themselves: when they know what they're doing, even if it's risky or obscure, they can do it. Students of C hate this aspect of C because it often seems as if the language is some kind of a conspiracy specifically designed to lead them into booby traps and ``gotcha!''s.

This is another aspect of the language which it's fairly pointless to complain about. If you take care and pay attention, you can avoid many of the pitfalls. These notes will point out many of the obvious (and not so obvious) trouble spots.

page 4

The last sentence of the Introduction is misleading: as we'll see, it's risky to defer to any particular compiler as a ``final authority on the language.'' A compiler is only a final authority on the language it accepts, and the language that a particular compiler accepts is not necessarily exactly C, no matter what the name of the compiler suggests. Most compilers accept extensions which are not part of standard C and which are not supported by other compilers; some compilers are deficient and fail to accept certain constructs which are in standard C. From time to time, you may have questions about what is truly standard and which neither you nor anyone you've talked to is able to answer. If you don't have a copy of the standard (or if you do, but you discover that the standardese in which it's written is impenetrable), you may have to temporarily accept the jurisdiction of your particular compiler, in order to get some program working today and under that particular compiler, but you'd do well to mark the code in question as suspect and the question in your head as ``don't know; still unanswered.''

Read sequentially: prev next up top