Chapter 1: Introduction
C is (as K&R admit) a relatively small language, but one which (to its admirers, anyway) wears well. C's small, unambitious feature set is a real advantage: there's less to learn; there isn't excess baggage in the way when you don't need it. It can also be a disadvantage: since it doesn't do everything for you, there's a lot you have to do yourself. (Actually, this is viewed by many as an additional advantage: anything the language doesn't do for you, it doesn't dictate to you, either, so you're free to do that something however you want.)
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 non portable 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 program 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.
A programming language is a tool, and no tool can perform every task unaided. If you're building a house, and I'm teaching you how to use a hammer, and you ask how to assemble rafters and trusses into gables, that's a legitimate question, but the answer has fallen out of the realm of ``How do I use a hammer?'' and into ``How do I build a house?''. In the same way, we'll see that C does not have built-in features to perform every function that we might ever need to do while programming.
As mentioned above, C imposes relatively few built-in ways of doing things on the programmer. Some common tasks, such as manipulating strings, allocating memory, and doing input/output (I/O), are performed by calling on library functions. Other tasks which you might want to do, such as creating or listing directories, or interacting with a mouse, or displaying windows or other user-interface elements, or doing color graphics, are not defined by the C language at all. You can do these things from a C program, of course, but you will be calling on services which are peculiar to your programming environment (compiler, processor, and operating system) and which are not defined by the C standard. Since this course is about portable C programming, it will also be steering clear of facilities not provided in all C environments.
Another aspect of C that's worth mentioning here is that it is, to put it bluntly, a bit dangerous. C does not, in general, try hard to protect a programmer from mistakes. If you write a piece of code which will (through some oversight of yours) do something wildly different from what you intended it to do, up to and including deleting your data or trashing your disk, and if it is possible for the compiler to compile it, it generally will. You won't get warnings of the form ``Do you really mean to...?'' or ``Are you sure you really want to...?''. C is often compared to a sharp knife: it can do a surgically precise job on some exacting task you have in mind, but it can also do a surgically precise job of cutting off your finger. It's up to you to use it carefully.
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.
1.1 A First Example
[This section corresponds to K&R Sec. 1.1]
The best way to learn programming is to dive right in and start writing real programs. This way, concepts which would otherwise seem abstract make sense, and the positive feedback you get from getting even a small program to work gives you a great incentive to improve it or write the next one.
Diving in with ``real'' programs right away has another advantage, if only pragmatic: if you're using a conventional compiler, you can't run a fragment of a program and see what it does; nothing will run until you have a complete (if tiny or trivial) program. You can't learn everything you'd need to write a complete program all at once, so you'll have to take some things ``on faith'' and parrot them in your first programs before you begin to understand them. (You can't learn to program just one expression or statement at a time any more than you can learn to speak a foreign language one word at a time. If all you know is a handful of words, you can't actually say anything: you also need to know something about the language's word order and grammar and sentence structure and declension of articles and verbs.)
Besides the occasional necessity to take things on faith, there is a more serious potential drawback of this ``dive in and program'' approach: it's a small step from learning-by-doing to learning-by-trial-and-error, and when you learn programming by trial-and-error, you can very easily learn many errors. When you're not sure whether something will work, or you're not even sure what you could use that might work, and you try something, and it does work, you do not have any guarantee that what you tried worked for the right reason. You might just have ``learned'' something that works only by accident or only on your compiler, and it may be very hard to un-learn it later, when it stops working.
Therefore, whenever you're not sure of something, be very careful before you go off and try it ``just to see if it will work.'' Of course, you can never be absolutely sure that something is going to work before you try it, otherwise we'd never have to try things. But you should have an expectation that something is going to work before you try it, and if you can't predict how to do something or whether something would work and find yourself having to determine it experimentally, make a note in your mind that whatever you've just learned (based on the outcome of the experiment) is suspect.
The first example program in K&R is the first example program in any language: print or display a simple string, and exit. Here is my version of K&R's ``hello, world'' program:
#include
main()
{printf("Hello, world!\n");return 0;
}
If you have a C compiler, the first thing to do is figure out how to type this program in and compile it and run it and see where its output went. (If you don't have a C compiler yet, the first thing to do is to find one.)
The first line is practically boilerplate; it will appear in almost all programs we write. It asks that some definitions having to do with the ``Standard I/O Library'' be included in our program; these definitions are needed if we are to call the library function printf correctly.
The second line says that we are defining a function named main. Most of the time, we can name our functions anything we want, but the function name main is special: it is the function that will be ``called'' first when our program starts running. The empty pair of parentheses indicates that our main function accepts no arguments, that is, there isn't any information which needs to be passed in when the function is called.
The braces { and } surround a list of statements in C. Here, they surround the list of statements making up the function main.
The line
printf("Hello, world!\n"); is the first statement in the program. It asks that the function printf be called; printf is a library function which prints formatted output. The parentheses surround printf's argument list: the information which is handed to it which it should act on. The semicolon at the end of the line terminates the statement.
(printf's name reflects the fact that C was first developed when Teletypes and other printing terminals were still in widespread use. Today, of course, video displays are far more common. printf's ``prints'' to the standard output, that is, to the default location for program output to go. Nowadays, that's almost always a video screen or a window on that screen. If you do have a printer, you'll typically have to do something extra to get a program to print to it.)
printf's first (and, in this case, only) argument is the string which it should print. The string, enclosed in double quotes "", consists of the words ``Hello, world!'' followed by a special sequence: \n. In strings, any two-character sequence beginning with the backslash \ represents a single special character. The sequence \n represents the ``new line'' character, which prints a carriage return or line feed or whatever it takes to end one line of output and move down to the next. (This program only prints one line of output, but it's still important to terminate it.)
The second line in the main function is
return 0; In general, a function may return a value to its caller, and main is no exception. When main returns (that is, reaches its end and stops functioning), the program is at its end, and the return value from main tells the operating system (or whatever invoked the program that main is the main function of) whether it succeeded or not. By convention, a return value of 0 indicates success.
This program may look so absolutely trivial that it seems as if it's not even worth typing it in and trying to run it, but doing so may be a big (and is certainly a vital) first hurdle. On an unfamiliar computer, it can be arbitrarily difficult to figure out how to enter a text file containing program source, or how to compile and link it, or how to invoke it, or what happened after (if?) it ran. The most experienced C programmers immediately go back to this one, simple program whenever they're trying out a new system or a new way of entering or building programs or a new way of printing output from within programs. As Kernighan and Ritchie say, everything else is comparatively easy.
How you compile and run this (or any) program is a function of the compiler and operating system you're using. The first step is to type it in, exactly as shown; this may involve using a text editor to create a file containing the program text. You'll have to give the file a name, and all C compilers (that I've ever heard of) require that files containing C source end with the extension .c. So you might place the program text in a file called hello.c.
The second step is to compile the program. (Strictly speaking, compilation consists of two steps, compilation proper followed by linking, but we can overlook this distinction at first, especially because the compiler often takes care of initiating the linking step automatically.) On many Unix systems, the command to compile a C program from a source file hello.c is
cc -o hello hello.c You would type this command at the Unix shell prompt, and it requests that the cc (C compiler) program be run, placing its output (i.e. the new executable program it creates) in the file hello, and taking its input (i.e. the source code to be compiled) from the file hello.c.
The third step is to run (execute, invoke) the newly-built hello program. Again on a Unix system, this is done simply by typing the program's name:
hello Depending on how your system is set up (in particular, on whether the current directory is searched for executables, based on the PATH variable), you may have to type
./hello to indicate that the hello program is in the current directory (as opposed to some ``bin'' directory full of executable programs, elsewhere).
You may also have your choice of C compilers. On many Unix machines, the cc command is an older compiler which does not recognize modern, ANSI Standard C syntax. An old compiler will accept the simple programs we'll be starting with, but it will not accept most of our later programs. If you find yourself getting baffling compilation errors on programs which you've typed in exactly as they're shown, it probably indicates that you're using an older compiler. On many machines, another compiler called acc or gcc is available, and you'll want to use it, instead. (Both acc and gcc are typically invoked the same as cc; that is, the above cc command would instead be typed, say, gcc -o hello hello.c .)
(One final caveat about Unix systems: don't name your test programs test, because there's already a standard command called test, and you and the command interpreter will get badly confused if you try to replace the system's test command with your own, not least because your own almost certainly does something completely different.)
Under MS-DOS, the compilation procedure is quite similar. The name of the command you type will depend on your compiler (e.g. cl for the Microsoft C compiler, tc or bcc for Borland's Turbo C, etc.). You may have to manually perform the second, linking step, perhaps with a command named link or tlink. The executable file which the compiler/linker creates will have a name ending in .exe (or perhaps .com), but you can still invoke it by typing the base name (e.g. hello). See your compiler documentation for complete details; one of the manuals should contain a demonstration of how to enter, compile, and run a small program that prints some simple output, just as we're trying to describe here.
In an integrated or ``visual'' progamming environment, such as those on the Macintosh or under various versions of Microsoft Windows, the steps you take to enter, compile, and run a program are somewhat different (and, theoretically, simpler). Typically, there is a way to open a new source window, type source code into it, give it a file name, and add it to the program (or ``project'') you're building. If necessary, there will be a way to specify what other source files (or ``modules'') make up the program. Then, there's a button or menu selection which compiles and runs the program, all from within the programming environment. (There will also be a way to create a standalone executable file which you can run from outside the environment.) In a PC-compatible environment, you may have to choose between creating DOS programs or Windows programs. (If you have troubles pertaining to the printf function, try specifying a target environment of MS-DOS. Supposedly, some compilers which are targeted at Windows environments won't let you call printf, because until you call some fancier functions to request that a window be created, there's no window for printf to print to.) Again, check the introductory or tutorial manual that came with the programming package; it should walk you through the steps necessary to get your first program running.
1.2 Second Example
Our second example is of little more practical use than the first, but it introduces a few more programming language elements:
#include
/* print a few numbers, to illustrate a simple loop */
main()
{int i;
for(i = 0; i < 10; i = i + 1)
printf("i is %d\n", i);return 0;
}
As before, the line #include
The first new line is the line
/* print a few numbers, to illustrate a simple loop */ which is a comment. Anything between the characters /* and */ is ignored by the compiler, but may be useful to a person trying to read and understand the program. You can add comments anywhere you want to in the program, to document what the program is, what it does, who wrote it, how it works, what the various functions are for and how they work, what the various variables are for, etc.
The second new line, down within the function main, is
int i; which declares that our function will use a variable named i. The variable's type is int, which is a plain integer.
Next, we set up a loop:
for(i = 0; i < 10; i = i + 1) The keyword for indicates that we are setting up a ``for loop.'' A for loop is controlled by three expressions, enclosed in parentheses and separated by semicolons. These expressions say that, in this case, the loop starts by setting i to 0, that it continues as long as i is less than 10, and that after each iteration of the loop, i should be incremented by 1 (that is, have 1 added to its value).
Finally, we have a call to the printf function, as before, but with several differences. First, the call to printf is within the body of the for loop. This means that control flow does not pass once through the printf call, but instead that the call is performed as many times as are dictated by the for loop. In this case, printf will be called several times: once when i is 0, once when i is 1, once when i is 2, and so on until i is 9, for a total of 10 times.
A second difference in the printf call is that the string to be printed, "i is %d", contains a percent sign. Whenever printf sees a percent sign, it indicates that printf is not supposed to print the exact text of the string, but is instead supposed to read another one of its arguments to decide what to print. The letter after the percent sign tells it what type of argument to expect and how to print it. In this case, the letter d indicates that printf is to expect an int, and to print it in decimal. Finally, we see that printf is in fact being called with another argument, for a total of two, separated by commas. The second argument is the variable i, which is in fact an int, as required by %d. The effect of all of this is that each time it is called, printf will print a line containing the current value of the variable i:
i is 0 i is 1 i is 2 ... After several trips through the loop, i will eventually equal 9. After that trip through the loop, the third control expression i = i + 1 will increment its value to 10. The condition i < 10 is no longer true, so no more trips through the loop are taken. Instead, control flow jumps down to the statement following the for loop, which is the return statement. The main function returns, and the program is finished.
1.3 Program Structure
We'll have more to say later about program structure, but for now let's observe a few basics. A program consists of one or more functions; it may also contain global variables. (Our two example programs so far have contained one function apiece, and no global variables.) At the top of a source file are typically a few boilerplate lines such as #include
Each function is further composed of declarations and statements, in that order. When a sequence of statements should act as one (for example, when they should all serve together as the body of a loop) they can be enclosed in braces (just as for the outer body of the entire function). The simplest kind of statement is an expression statement, which is an expression (presumably performing some useful operation) followed by a semicolon. Expressions are further composed of operators, objects (variables), and constants.
C source code consists of several lexical elements. Some are words, such as for, return, main, and i, which are either keywords of the language (for, return) or identifiers (names) we've chosen for our own functions and variables (main, i). There are constants such as 1 and 10 which introduce new values into the program. There are operators such as =, +, and >, which manipulate variables and values. There are other punctuation characters (often called delimiters), such as parentheses and squiggly braces {}, which indicate how the other elements of the program are grouped. Finally, all of the preceding elements can be separated by whitespace: spaces, tabs, and the ``carriage returns'' between lines.
The source code for a C program is, for the most part, ``free form.'' This means that the compiler does not care how the code is arranged: how it is broken into lines, how the lines are indented, or whether whitespace is used between things like variable names and other punctuation. (Lines like #include
The usage of whitespace is our first style issue. It's typical to leave a blank line between different parts of the program, to leave a space on either side of operators such as + and =, and to indent the bodies of loops and other control flow constructs. Typically, we arrange the indentation so that the subsidiary statements controlled by a loop statement (the ``loop body,'' such as the printf call in our second example program) are all aligned with each other and placed one tab stop (or some consistent number of spaces) to the right of the controlling statement. This indentation (like all whitespace) is not required by the compiler, but it makes programs much easier to read. (However, it can also be misleading, if used incorrectly or in the face of inadvertent mistakes. The compiler will decide what ``the body of the loop'' is based on its own rules, not the indentation, so if the indentation does not match the compiler's interpretation, confusion is inevitable.)
To drive home the point that the compiler doesn't care about indentation, line breaks, or other whitespace, here are a few (extreme) examples: The fragments
for(i = 0; i < 10; i = i + 1)
printf("%d\n", i); and
for(i = 0; i < 10; i = i + 1) printf("%d\n", i); and
for(i=0;i<10;i=i+1)printf("%d\n",i); and
for(i = 0; i < 10; i = i + 1)printf("%d\n", i); and
for ( i
= 0 ;
i < 10
; i =
i + 1
) printf (
"%d\n" , i
) ; and
for (i=0; i<10;i=i+1)printf
("%d\n", i); are all treated exactly the same way by the compiler.
Some programmers argue forever over the best set of ``rules'' for indentation and other aspects of programming style, calling to mind the old philosopher's debates about the number of angels that could dance on the head of a pin. Style issues (such as how a program is laid out) are important, but they're not something to be too dogmatic about, and there are also other, deeper style issues besides mere layout and typography. Kernighan and Ritchie take a fairly moderate stance:
Although C compilers do not care about how a program looks, proper indentation and spacing are critical in making programs easy for people to read. We recommend writing only one statement per line, and using blanks around operators to clarify grouping. The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.
There is some value in having a reasonably standard style (or a few standard styles) for code layout. Please don't take the above advice to ``pick a style that suits you'' as an invitation to invent your own brand-new style. If (perhaps after you've been programming in C for a while) you have specific objections to specific facets of existing styles, you're welcome to modify them, but if you don't have any particular leanings, you're probably best off copying an existing style at first. (If you want to place your own stamp of originality on the programs that you write, there are better avenues for your creativity than inventing a bizarre layout; you might instead try to make the logic easier to follow, or the user interface easier to use, or the code freer of bugs.)
No comments:
Post a Comment