lafore_robert_objectoriented_programming_in_c

We’ll see an important example of a class library in Chapter 15, “The Standard Template Library.”

A class library usually includes two components: the interface and the implementation. Let’s see what the difference is.

Interface

Let’s say that the person who wrote a class library is called the class developer, and the person who uses the library is called the programmer.

To use a class library, the programmer needs to access various declarations, including class declarations. These declarations can be thought of as the public part of the library and are usually furnished in source-code form as a header file, with the .H extension. This file is typically combined with the client’s source code using an #include statement.

The declarations in such a header file need to be public for several reasons. First, it’s a convenience to the client to see the actual class definitions rather than to have to read a description of them. More importantly, the programmer will need to declare objects based on these classes and call on member functions from these objects. Only by declaring the classes in the source file is this possible.

These declarations are called the interface because that’s what a user of the class (the programmer) sees and interacts with. The programmer need not be concerned with the other part of the library, the implementation.

Implementation

On the other hand, the inner workings of the member functions of the various classes don’t need to be known by the programmer. The class developers, like any other software developers, don’t want to release source code if they can help it, since it might be illegally modified or pirated. Member functions—except for short inline functions—are therefore often distributed in object form, as .OBJ files or as library (.LIB) files.

Figure 13.1 shows how the various files are related in a multifile system.

Organization and Conceptualization

Programs may be broken down into multiple files for reasons other than the accommodation of class libraries. As in other programming languages, a common situation involves a project with several programmers (or teams of programmers). Confining each programmer’s responsibility to a separate file helps organize the project and define more cleanly the interface among different parts of the program.

13

PROGRAMS MULTIFILE

Suppose that you have purchased a prewritten class file called THEIRS.OBJ. (A library file with the .LIB extension is dealt with in much the same way.) It probably comes with a header file, say THEIRS.H. You have also written your own program to use the classes in the library; your source file is called MINE.CPP. Now you want to combine these component files—THEIRS.OBJ, THEIRS.H, and MINE.CPP—into a single executable program.

Header Files

The header file THEIRS.H is easily incorporated into your own source file, MINE.CPP, with an #include statement:

#include “theirs.h”

Quotes rather than angle brackets around the filename tell the compiler to look for the file in the current directory, rather than in the default include directory.

Directory

Make sure that all the component files, THEIRS.OBJ, THEIRS.H, and MINE.CPP, are in the same directory. In fact, you will probably want to create a separate directory for each project, to avoid confusion. (This isn’t strictly necessary, but it’s the simplest approach.)

Each compiler keeps its own library files (such as IOSTREAM and CONIO.H) in a particular directory, often called INCLUDE, and usually buried many levels down in the compiler’s directory structure. The compiler already knows where this directory is.

You can also tell the compiler about other include directories that you create yourself. You may want to keep some of your header files in such a directory, where they will be available for several projects. In Appendix C, “Microsoft Visual C++,” and Appendix D, “Borland C++Builder,” we explain how to tell the compiler where such a directory is located.

Projects

Most compilers manage multiple files using a project metaphor. A project contains all the files necessary for the application. It also contains instructions for combining these files, often in a special file called a project file. The extension for this file varies with the compiler vendor. It’s

.BPR for Borland, and .DSP for Microsoft. Modern compilers construct and maintain this file automatically, so you don’t need to worry about it. In general you must tell the compiler about all the source (.CPP) files you plan to use so they can be added to the project. You can add .OBJ and .LIB files in a similar way. Appendixes C and D provide details on creating multifile programs for specific compilers.

13

PROGRAMS MULTIFILE

Multifile Programs

Most declarations are also definitions. Actually, the only declaration of a simple variable that is not a definition uses the keyword extern (with no initializer).

As you might expect, a global variable can be defined in only one place in a program.

//file A

int globalVar; //definition in file A

//file B

int globalVar; //illegal: same definition in file B

Of course, this discussion applies only to global variables. You can define as many variables with the same name and type as you like, provided they are all local to different functions or classes.

How do you access a global variable in one file from a different file? The fact that the linker will object to defining the same global variable in more than one file does not mean that a variable in one file is automatically visible to all code in other files. You must declare the variable in every file that uses it. If you say

//file A

int globalVar; //defined

//file B

globalVar = 3; //illegal, globalVar is unknown here

the compiler will tell you that globalVar is an unidentified identifier.

To allow a variable to be accessed in files other than the one where it’s defined, you must declare it in the other files using the keyword extern.

The declaration causes globalVar in file A to be visible in file B. The extern keyword signals that the declaration is only a declaration, not a definition. It tells the compiler (which can see only one file at a time) not to worry that the globalVar variable in file B is undefined there. The linker (which sees all the files) will take care of connecting a reference to a variable in one file with its definition in another.

639

13

PROGRAMS MULTIFILE

Here, file B has access to the const variable in file A. The compiler can tell the difference between a const definition and a declaration by seeing where the variable is initialized.

Inter-File Functions

Remember that a function declaration specifies the name of the function, its return type, and the type of any arguments. A function definition is a declaration that includes a function body. (The body is the code within braces.)

When the compiler generates a call to a function, it doesn’t need to know how the function works. All it needs to know is the function name, its return type, and the types of its arguments. This is exactly what the declaration specifies. It is therefore easy to define a function in one file and make calls to it from a second file. No extra keywords (like extern) are needed. All that’s necessary is to declare the function in the second file before making calls to it.

//file A

int add(int a, int b) //function definition

{ return a+b; } //(includes function body)

//file B

int add(int, int); //function declaration (no body)

. . .

int answer = add(3, 2); //call to function

You don’t need to use the keyword extern with functions because the compiler can tell the difference between a function’s declaration and definition: the declaration has no body.

Incidentally, you can declare (not define) a function or any other program element as many times as you want. The compiler won’t object, unless the declarations disagree.

//file A

int add(int, int); //declaration

int add(int, int); //another declaration is OK

Like variables, functions can be made invisible to other files by declaring them static.

//file A

static int add(int a, int b) //function definition { return a+b; }

//file B

static int add(int a, int b) //different function { return a+b; }

13

PROGRAMS MULTIFILE

However, for a class, the entire definition is necessary to specify the types of its member data and functions.

A mere declaration is insufficient for the compiler to generate code to deal with class objects (except for pointers and references to objects).

You can’t define a class more than once in a source (.CPP) file, but every source file in a program can have its own definition of the same class. Indeed, it must have such a definition if it is to work with objects of that class. In the next section we’ll show how to use a header file to supply a class definition to many files.

Header Files

As we noted in Chapter 2, the #include preprocessor directive acts like the paste function in a word processor, causing the text of one file to be inserted in another. We’ve seen many examples of library files such as IOSTREAM being included in our source files.

We can also write our own header (usually .H) files and include them in our source files.

Common Information

One reason to use a header file is to supply two or more source files with the same information. The header file holds variable or function declarations, and is included in the source files. In this way the variables or functions can be accessed from many files.

Of course, each program element must also be defined somewhere. Here, a variable and a function are declared in FILEH.H and defined in FILEA.CPP. Code in FILEB.CPP can then use these elements without any additional declarations of its own.

13

PROGRAMS MULTIFILE