UMBC CMSC202, Computer Science II, Spring 1998, Sections 0101, 0102, 0103, 0104 and Honors

Thursday March 12, 1998

Assigned Reading:

• A Book on C: 10.1 - 10.4
• Programming Abstractions in C: 12.1 - 12.3

Handouts (available on-line): none. (The course syllabus mentions on-line reading material. I had intended to use the material from previous semesters. However, I want to present linked lists in a different manner, so we won't be using those notes.)

Topics Covered:

• We covered another example of why we need to make functions and global variables private using the "static" storage class. In this example, we have a simple interface for a function called StringLength(). (See header file and implementation.)
  • In the straightforward use of the StringLength() function, the main program simply includes the header file slength.c and calls StringLength() as usual. The sample run shows nothing unusual.
  • In the next example, the main program happens to include a global variable called strlen. This creates a naming conflict because strlen is of course the name of the standard function in the string.h library that StringLength() uses to find the length of the string. One sample run on an SGI Indigo running the IRIX 5.3 operating system shows that the compiler gave no warning and no errors for this naming conflict. Running the compiled program causes a core dump. The next sample run is produced on an SGI running IRIX 6.2. This version of the compiler at least gives some warning about the naming conflict. Nevertheless, the compiler produces an executable file which dumps core.
  • Our next main program and sample run shows that the proper way to resolve the naming conflict is to make the strlen global variable a private variable.
  One response to the example above is that you shouldn't use global variables in the first place. This is not a valid point because the same problem occurs if you have a function called strlen. Since it is unreasonable to require that programmers know the names of all functions that might eventually be linked into their programs, it is best to adopt the strategy that one should make private those functions and global variables that are not to be used by other functions.

• We started looking at the list abstract data type (ADT). A sample run of our program shows what we want to accomplish using this abstract data type. The main program which uses the list ADT should not need to know how the ADT is implemented. All access to data stored in the list should be through function calls. Sometimes this seems silly because it is simpler to access the data directly. However, separating the main program from the implementation of the ADT in such a manner allows us to change the implementation of the list without having to change the main program. This division of labor is necessary in the development of large programs because it reduces the complexity of the code.

• We then examined the interface and the implementation of the list ADT using linked lists in greater detail. Note the use of the special header node at the the beginning of the list. This simplifies our code greatly and eliminates the need for special cases to handle insertions at the beginning of a list or appending to an empty list. We will finish this example in the next lecture.