Problem Session 4 Header Files and Unix. Where are they? You may need to examine the header file to determine what the data structures and functions provided are. Sometimes having a book like P.J. Plauger: The Standard C Library is not quite enough - different versions of Unix may have subtly different versions of the libraries, and you may or may not be able to determine what you are working with, without looking "under the hood".. Since the files are invoked by #include you should be able to find them in the "sensible place": /usr/include...

Problem Session 4 Let's look at one - the one. It contains lots of information that we have to navigate through. There are function prototypes - without any explanation or documentation: you are expected to have a text or some other separate documentation to make any sense of what's there. Some of the function names "make sense", some others appear to be unpronounceable collections of letters.

Problem Session 4 When your program contains #include this is the header file it will "textually include" in the source code to be compiled. The presence of the <> symbols indicates this is a system file, and will be found in a directory set up by the system administrators, and known to our compiler. The system will maintain information about the need to link - and some intelligent linkers will link only the functions actually used, thus minimizing the amount of space your program uses.

Problem Session 4 What about the beginning lines? #ifndef _STRING_H_ #define _STRING_H_ #ifdef __cplusplus extern "C" { #endif They are certainly not like regular program code. Furthermore, if you look this up in Plauger's book in the hope of getting some clarification, you will find: #ifndef _STRING #define _STRING #ifndef _YVALS #include #endif

Problem Session 4 Then What? Plauger's book doesn't say much about the "C preprocessor" - you have to go to something like Harbison&Steele: C - A Reference Manual; or Kernighan&Ritchie: The C Programming Language. Essentially, every line beginning with # is going to be interpreted as providing some kind of directive or information to the compiler. We are familiar with #include ; we may even be familiar with something like #define MAX_VAL 100 which would introduce a "symbolic constant" with a value of this would simply mean that every occurrence of MAX_VAL in our source code will be replaced by 100 before compilation.

What about: #ifndef _STRING_H_ #define _STRING_H_ This would introduce a symbolic constant _STRING_H _, but without any associated value. Notice that the first line is a conditional: #ifndef (same as #if ! defined ) checks whether the compiler is aware of the existence of that symbolic constant. If it is, it will skip to the #endif. If not, it will declare it and perform (in this case) some other actions. Problem Session 4

Why would you do this? Symbolic constants can be defined in several different header files. At times you will need to include two or more files defining the same symbolic constant. To avoid possible conflicts, you check and do not repeat actions already taken. There is another problem: your main program and one of the modules you need, have to have access to common information. You put the information into a file, but you will have TWO ways this file is read into your source code at compilation. The system will object to having multiple definitions of functions and data structures.

Problem Session 4 You avoid the problem by having a symbolic constant associated with every header file you write, and you perform a check for compiler awareness of the symbolic constant: if the check fails, the header file is safe to be read in; if the check succeeds, it has already been read in, so you skip it.

#ifndef GRAPH_H #define GRAPH_H typedef struct vertex{ int Number; bool Visited; } Vertex; typedef struct edge{ Vertex From; Vertex To; } Edge; typedef struct graph{ int N_Vertices; /* maximum of 20 */ int N_Edges; /* maximum of 30 */ Vertex Vertices[20]; Edge Edges[30]; } Graph; #endif // GRAPH_H Problem Session 4 Example of #ifndef