| | | | | | |
Now that you know how to create and edit files, you can generate new programs. The most commonly used languages in the CS Department at the moment are C++, C, and Java.
The most popular C++ and C compilers are g++ and gcc.38
Although not really a Unix-specific topic, it's hard to discuss how to compile code under any operating system without a basic understanding how programs are put together.
The source code for a C++ (or C) program is contained in a number of text files called source files. Very simple programs might be contained within a single source file, but as our programs grow larger and more complicated, programmers try to keep things manageable by splitting the code into multiple source files, no one of which should be terribly long.
There are two different kinds of source files: header files and non-header files. Header files are generally given names ending in “.h” . Non-header files are generally given names ending in “.cpp” for C++ code and “.c” for C code.39
There are variations, particularly for C++. Other less common endings accepted by some C++ compilers for non-header files include “.C” “.cc” and “.cxx” .
Header and non-header files are treated differently when we build programs. Each non-header file is compiled separately from the others (). This helps keep the compilation times reasonable, particularly when we are fixing bugs in a program and may have changed only one or two non-header files. Only those changed files need to be recompiled.
Header files are not compiled directly, Instead, header files are included into other source files via #include. In fact, when you invoke a C/C++ compiler, before the “real” compiler starts, it runs a pre-processor whose job is to handle the special instructions that begin with #. In the case of #include statements, the pre-processor simply grabs the relevant header file and sticks its content into the program right at the spot of the #include.
|
|
This can result in a dramatic increase in the amount of code that actually gets processed. The code shown here, for example, is pretty basic. But the #include statements bring in an entire library of I/O and string-related declarations from the C++ standard library. Here, for example, is the output of the pre-processor for one compiler. (If you look at the very end, you can recognize the main code for this program.)
A header file can be #included from any number of other header and non-header files. That is, in fact, the whole point of having header files. Header files should contain declarations of things that need to be shared by multiple other source files. Non-header files should declare only things that do not need to be shared.
As we go through all thecompilation steps required to build a program, anything that appears in a non-header file will be processed exactly once by the compiler. Anything that appears in a header file may be processed multiple times by the compiler.
The short answer is that a header file contains shared declarations, a non-header file contains definitions and local (non-shared) declarations.
Pretty much everything that has a “name” in C++ must be declared before you can use it. Many of these things must also be defined, but that can generally be done at a much later time.
You declare a name by saying what kind of thing it is:
In most cases, once you have declared a name, you can write code that uses it. Furthermore, a program may declare the same thing any number of times, as long as it does so consistently. That's why a single header file can be included by several different non-header files that make up a program - header files contain only declarations.
You define constants, variables, and functions as follows:
When a non-header file is compiled, we get an object-code file, usually ending in “.o” . These are binary files that are “almost” executable - for some variables and functions, instead of the actual address of that variable/function, they still have its name. This happens when the variable or function is decalred but not defined in that non-header file (after expansion of #includes by the pre-processor). That name will be assigned an address only when a file contianing a definition of that name is compiled. And that address will only be recorded in the object code file corresponding to the non-header source file where the name was defined.
The complete executable program is then produced by linking all the object code files together. The job of the linker is to find, for each name appearing in the object code, the address that was eventually assigned to that name, make the substitution, and produce a true binary executable in which all names have been replaced by addresses.
Understanding this difference and how the entire compilation/build process works (Figure 15: Building 1 program from many files) can help to explain some common but confusingly similar error messages:
If the compiler says that a function is undeclared, it means that you tried to use it before presenting its declaration, or forgot to declare it at all.
The compiler never complains about definitions, because an apparently missing definition might just be in some other non-header file you are going to compile later. But when you try to produce the executable program by linking all the compiled object code files files produced by the compiler, the linker may complain that a symbol is
undefined (none of the compiled files provided a definition) or is
multiply defined (you provided two definitions for one name, or somehow compiled the same definition into more than one object-code file).
For example, if you forget a function body, the linker will eventually complain that the function is undefined. If you put a variable or function definition in a .h file and include that file from more than one place, the linker will complain that the name is multiply defined.
There are variations, particularly for C++. Other less common endings accepted by some C++ compilers for non-header files include “.C” “.cc” and “.cxx” .
(back)The simplest case for each compiler involves compiling a single-file program (or a program in which all files are combined by #include statements). For example, use an editor to prepare the following files:
hello.cpp
hello.c
To compile and run these, the commands are:
A typical program will consist of many .cpp files. (See Figure 15: Building 1 program from many files) Usually, each class or group of utility functions will have their definitions in a separate .cpp file that defines everything declared in the corresponding .h file. The .h file can then be #included by many different parts of the program that use those classes or functions, and the .cpp file can be separately compiled once, then the resulting object code file is linked together with the object code from other .cpp files to form the complete program.
Splitting the program into pieces like this helps, among other things, divide the responsibility for who can change what and reduces the amount of compilation that must take place after a change to a function body.
When you have a program consisting of multiple files to be compiled separately, add a -c option to each compilation. This will cause the compiler to generate a .o object code file instead of an executable. Then invoke the compiler on all the .o files together without the -c to link them together and produce an executable:
Actually, you don't have to type separate compilation commands for each file. You can do the whole thing in one step:
Another useful option in these compilers is -D. If you add an option -Dname=value, then all occurrences of the identifier name in the program will be replaced by value. This can be useful as a way of customizing programs without editing them. If you use this option without a value, -Dname, then the compiler still notes that name has been “defined” . This is useful in conjunction with compiler directive #ifdef, which causes certain code to be compiled only if a particular name is defined. For example, many programmers will insert debugging output into their code this way:
Zeil's 2nd Rule of Debugging: Never leave your debugging code active when you submit your programs for grading. If the grader is using an automatic program to check the correctness of the output, unexpected output will make your program fail the tests. On the other hand, if the grader is reading the output to check its correctness, wading through extra output really ticks the grader off!
Sometimes your program may need functions from a previously-compiled library. For example, the sqrt and other mathmatical functions are kept in the “m” library (the filename is actually libm.a). To add functions from this library to your program, you would use the “-lm” option. (The “m” in “-lm” is the library name.) This is a linkage option, so it goes at the end of the command:
Here is a summary of the most commonly used options41
Programming windowing code is a fairly involved process. I suggest getting a library that simplifies this process for beginners. The V library is a good choice, and has the additional advantage that code written for use with V can be compiled to produce either Microsoft Windows or Unix X windows programs.
| Compilation Flags | |
|---|---|
| -c | compile only, do not link |
| -o filename | Use filename as the name of the compiled program |
| -Dsymbol=value | Define symbol during compilation. |
| -g | Include debugging information in compiled code (required if you want to be able to run the gdb debugger. |
| -O | Optimize the compiled code (produces smaller, faster programs but takes longer to compile) |
| -I directory | Add directory to the list of places searched when a ``system'' include (#include …) is encountered. |
| Linkage Flags | |
| -L directory | Add directory to the list of places searched for pre-compiled libraries. |
| -llibname | Link with the precompiled library liblibname.a |
Zeil's 2nd Rule of Debugging: Never leave your debugging code active when you submit your programs for grading. If the grader is using an automatic program to check the correctness of the output, unexpected output will make your program fail the tests. On the other hand, if the grader is reading the output to check its correctness, wading through extra output really ticks the grader off!
(back)Programming windowing code is a fairly involved process. I suggest getting a library that simplifies this process for beginners. The V library is a good choice, and has the additional advantage that code written for use with V can be compiled to produce either Microsoft Windows or Unix X windows programs.
(back)Unfortunately, once you start writing your own code, you will almost certainly make some mistakes and get some error messages from the compiler.
This is likely to lead to two problems: reading the messages, and understanding the messages.
Unless you are a far better programmer than I, you will not only get error messages, you will get so many that they overflow your telnet/xterm window.
How you handle this problem depends upon what command shell you are running, but there are two general approaches. You can use redirection and pipes to send the error messages somewhere more convenient, or you can use programs that try to capture all output from a running program (i.e., the compiler).
We've talked before about how many Unix commands are “filters” , working from a single input stream and producing a single output stream. Actually, there are 3 standard streams in most operating systems: standard input, standard output, and standard error. These generally default to the keyboard for standard input and the screen for the other two, unless either the program or the person running the program redirects one or more of these streams to a file or pipes the stream to/from another program.
We introduced pipes and redirection earlier. The complicating factor here is that what you want to pipe or redirect is not the standard output stream, but the standard error stream. So, for example, doing something like
How you pipe or redirect the standard error stream depends on the shell you are running:
There are other ways to capture the output of a compiler (or of any running program). You can run the compiler within the emacs editor, which then gives you a simple command to move from error message to error message, automatically bringing up the source code file on the line cited in the error message. This works with both the Unix and the MS Windows ports of emacs, and is the technique I use myself. vim, the “vi improved” editor will do the same.
Finally, in Unix there is a command called "script" that causes all output to your screen to be captured in a file. Just say
Cascading:
One thing to keep in mind is that errors, especially errors in declarations, can cascade, with one “misunderstanding” by the compiler leading to a whole host of later messages. For example, if you meant to write
Backtracking:
A compiler can only report where it detected a problem. Where you actually committed a mistake may be someplace entirely different.
The vast majority of error messages that C++ programmers will see are
Let's look at these from the point of view of the compiler.
If the compiler reads another line, and discovers that you had written:
Now, things can be much worse. Suppose that inside a file foo.h you write
So, with syntax errors, you know only that the real mistake occurred on the line reported or earlier, possibly in an earlier-#include'd file.
Here's an example taken from a student's code:
The problem is a “no match for” a less-than operator call in line 43 of a template within the standard library file stl<under></under>relops.h. But that template is instantiated from the student's own code (adjpq.h) and so the thing to do is to look at those three lines (234, 177, and 84) for a data type that is supposed to support a less-than operator, but doesn't.
Java programs get compiled into object code for an imaginary CPU called the “Java Virtual Machine” (JVM). Consequently, you can't execute compiled Java code directly. You must run a program that simulates a JVM and let that simulated computer execute the Java code.
That may seem a little convoluted, but the JVM simulator is easier to write than a “true” compiler. Consequently, JVM simulators can be built into other programs (such as web browsers), allowing Java code compiled on one machine to be executed on almost any other machine. By contrast, a true native-code compiler (e.g., g++) produces executables that can only be run on a single kind of computer.
The command to compile Java code is “javac” ( “c” for compiler) and the command to execute compiled Java code is “java” . So a typical sequence to compile and execute a single-file Java program would be
If we have a program that consists of multiple files, we can simply compile each file in turn:
So, if the file MyProgram.java looked like this
Java programs come in two forms: applets and applications. Applets are placed on web servers and can be launched from HTML web pages so that the Java code runs whenever someone browses that page. Applications, on the other hand, are more like traditional programs that get invoked directly by the user.
To run a Java application, we use java: