UMBC CMSC201, Computer Science I, Fall 1994 Sections 0101, 0102 and Honors

Tuesday October 25, 1994

Assigned Reading: 7.1 & 8.1

Handouts (available on-line): Project 3

Topics Covered:

• We discussed how to break up a large program into smaller pieces. One advantage of doing this is that compilation time is reduced during the development process because you only recompile the code that you changed, instead of the whole program. A more general question is how to make functions that you have written available to other programmers.
• Example 1: our calendar program.
  • First we look at the entire calendar program. In this version, the whole program is in one file. The sample run is what we expect.
  • In the next version of the calendar program, we break up the program into three pieces. First, we have the main program. Note that the main program includes the header file calendar.h which holds the constant definitions and the function prototypes. The third part is the file cal-funcs.c which contains the actual implementations of the functions. Note that the header file calendar.h is also included by cal-funcs.c. The functions in cal-funcs.c can be compiled separately and linked with the main program using these UNIX commands.
  • The same calendar functions can be used in a program that computes the date of Thanksgiving on a given year. In this case, the calendar functions do not have to be recompiled as the following sample run shows.
• We looked at separate compilations in greater detail. We broke up a large program that calls many functions into three pieces. (See sample run.) The pieces are the main program, the implementation of the functions and the header file. The main program and the implementations are compiled separately and linked together to make the a.out file using these UNIX commands.
• We reviewed what #include really means. We took the Hello World program and put the printf statement in a separate file called print.c. You would not ordinarily include a .c file. This is an example to show the effect of the #include preprocessor directive when the program is compiled.
• We could have broken up our main program into two pieces with the main program in one file and the functions included as a separate file. But this is a BAD approach because it does not hide the function implementation from the client and the functions have to be recompiled every time the main program changes. (See sample run.)
• Next we created an honest-to-goodness C library which contains all of the functions in the big program above. First we made each function into a separate file. So we have avg.c, dist.c, max.c, min.c, sum.c and print_cos_avg.c. We also had a header file with the function prototypes of all the functions. We compiled the functions separately using the -c option to create the .o object-code files. Then, we used the archive command ar to make a library called libmine.a. Finally, we compiled the main program separately by telling the cc201 command the name of the library and where to find it. (See the UNIX commands for making this library.)
• So, two things about the compilation process should be clearer now. First, the cc201 command is just the standard UNIX cc command with additional options telling the compiler where to find the include files, which libraries to use, and where the libraries are. Also, the header files, like simpio.h, mostly just contain a whole bunch of function prototypes.