we are not only declaring that a variable with the name 'myNumber' exists in the program, we are also setting aside a specific memory location for this variable - we are defining the variable. As it stands, the memory location for this variable contains garbage at this point.

Similarly, if we write the line:

we are requesting that the system set aside enough memory for a contract, give that memory area the symbolic name 'contract1', and don't put anything into that memory. In other words, let the memory hold whatever garbage is left over from its last use.

In all prior variable declarations (and 'contract1' is now a variable) we would picture the memory set aside as a box big enough to hold a value of whatever type was being declared. Doubles required larger boxes than integers which required larger boxes than chars. For variables that are instances of some class we need to think of memory as a big box with compartments - one compartment for each property. The compartments, of course, will be of different sizes, depending on whether the properties are of type int, char, or double - or even of some class. (Because classes are essentially new types, they can be used wherever types are used and, just as we can use 'if' statements inside 'whiles' inside 'if's etc., we can use classes as type names inside class declarations.)

Back to our instantiations of contract, here is our code after declaring the five instances.

// Program to test the functionality of the class 'contract'
// File: ch5tst1.cpp

#include <iostream.h>
#include "contract.h"


void main()
{

Contract contract1;
Contract contract2;
Contract contract3;
Contract contract4;
Contract contract5;
.
.
}

Be sure you understand that five distinct memory areas have been set aside, each of which represents a separate instance of the 'contract' class with its own memory locations holding the values for the three properties. (Remember, these properties are formally called 'data members'.) To ensure that you understand this notion, here is a representation of memory containing these five instances.

B. Using the Change.... Member Functions to Initialize the Instances
As Figure 5.2 shows, the five instances all contain garbage. To initialize these instances to the property values we decided on above, we can use the 'Change... functions. Think of these instances as animate objects and that we are going to send each instance a series of messages telling it the values of its properties. Here are the names for the messages we want to send:

ChangeSquareFootage
ChangeNumberOfDesks
ChangeNumberOfDays

as we might have done with regular functions in chapter four. Member functions always work with specific instances of a class but in this code the computer has no way of knowing for which instance we want to change the square footage.

Suppose we want to change the square footage first for the instance 'contract1' - a logical choice. The code for this would be written:

To change the number of desks for contract2, we would write:

Here we are sending the same message but we are sending it to contract2.

The code to initialze all the data members of all the instances is similar. It would be placed right after the five declarations as in:

void main()
{	Contract contract1;
	Contract contract2;
	Contract contract3;
	Contract contract4;
	Contract contract5;

	// Initializing contract1
	contract1.ChangeSquareFootage(1000);
	contract1.ChangeNumDesks(3);
	contract1.ChangeNumDays(5);

	// Initializing contract2
	contract2.ChangeSquareFootage(500);
	contract2.ChangeNumDesks(10);
	contract2.ChangeNumDays(3);

	// Initializing contract3
	contract3.ChangeSquareFootage(200);
	contract3.ChangeNumDesks(1);
	contract3.ChangeNumDays(4);

	// Initializing contract4
	contract4.ChangeSquareFootage(200);
	contract4.ChangeNumDesks(20
	contract4.ChangeNumDays(5);

	// Initializing contract5
	contract5.ChangeSquareFootage(300);
	contract5.ChangeNumDesks(2);
	contract5.ChangeNumDays(2);

.
.
}

Figure 5.3 shows how the memory for the contracts would look after this code is executed.

C. Using the Provide.... Member Functions
OK, so now we have initialized our five instances! How do we display their property values to test that the declarations and Change functions worked properly? (Remember, the sole purpose of this program is to test our code.) We can again think of these instances as animate objects and that we are going to send each instance a series of messages, asking it for the values of its properties. Here are the names for the messages we want to send:

ProvideSquareFootage
ProvideNumberOfDesks
ProvideNumberOfDays
ProvidePerWeekCharge

These, of course, are the names of the member functions whose purpose is to return (provide) the specific information asked for. You might object that the "per week charge" is not a property. It is true that it is not a data member of the instances, but it is a value that we, as designers of the class 'contract', have agreed to provide to any program that creates instances of the class. It is irrelevant to users of this how the information is given, just that it is given on demand.

(By "users" we again mean programmers who take advantage of the design and code created for this class by including the code in their programs. Since, at this point, you are acting as designer of all classes and all programs that use the classes, this may be hard to grasp. After all, you know all the details of all aspects of your code. Try to imagine a situation where hundreds of programmers are involved in designing dozens of classes to be used in numerous different programs. Or, imagine yourself re-using a class you designed and coded but whose inner workings you have long since forgotten.)

In any case, as before, to use these functions we can't just write, for example:

As was said above, member functions always work with specific instances of a class so in this code the computer has no way of knowing from which instance we want to get the square footage.

Suppose we want the square footage first from the instance 'contract1'. The code for this would be written:

This is a call to the function 'ProvideSquareFootage' associated with the instance 'contract1'. We can read this as "Send a message to contract1 to provide its square footage and store what contract1 returns in the memory location symbolized by the local variable 'sqFootage'."

We could then write the code:

to output the square footage returned.

Similarly, to retrieve and output the per week charge for contract 1 we could write:

double charge;
charge = contract1.ProvidePerWeekCharge();
cout << "The per week charge for contract 1 is: " << charge << endl;

hoping to get access to the data member of some instance without making any function calls. This fails for two reasons. First, each instance has its own memory location called 'squareFootage' so how does the computer know which instance we want? Second, the data members are encapsulated so, even if there was only one instance, we would not be able to get direct access to its data members.

Could we fix the problem by writing:

as we did with function members to indicate which instance we are interested in? Note that this does indicate which instance we are interested in, BUT it has no effect on the encapsulation issue. The only way to get access to those parts of a class that are declared to be private is through the appropriate member functions. This is a bit like walking into a post office to pick up a package. You may know that a package is somewhere 'behind the counter' but you do not have direct access to it. You must ask a clerk to go back and get it for you.

D. Changing Property Values
The next step we decided to take in our test program was to change the property values of some instances. Here is the table again of changes. (Remember, blanks in the table refer to properties that will not be changed):

There are six changes that need to be made so we have six function calls to write. The form of the calls is the same as in the previous set of change instructions.To change the 'number of desks' value in contract 1 we write:

The calls to the others look the same:

Note that contracts 2 and 4 each have two function calls (are sent two messages) because two property values are changed. Note also that we cannot directly change the per week charge for any instance. Since there is no data member for this 'property', no member function is included to directly change its value. However, any change to any of the other three properties will result in a change in the per week charge when it is re-calculated.

To make sure that these changes work, we next output the four values of the properties of the five instances. This is simply a repeat of the code you saw above. You are urged to complete this yourself. Include the necessary code to output the property values of instance five, even though no changes were made to it, in order to make sure your code does not accidentally make changes it should not make. You should then run this program and see if the outputs generated are what you expect - see "Putting it All Together" below. When you are finished, check out the authors' version of this code under the file names, "contract.h", "contract.cpp", and "ch5tst1.cpp"

E. Putting It All Together
Prior to this, we used functional decomposition to break up the code. However, we kept all the code in one file with the exception of some built-in header files. Now we have split up the code into two separate '.cpp' files and one header files. To allow our program to function as a single unit, we need to bring these files back together.

We have already seen how to accomplish part of this through the use of header files and the include statement. As we said, the "#include …" statement copies the code in the included file into the file containing the "#include" statement. This is standard in all versions of C++. However, bring together or linking the .cpp files is not so standard across C++ packages.

First, we need to understand a bit about the C/C++ heritage and approach to programming. It has always been considered very important in the 'C' world that one be allowed to compile parts of a program separate from other parts. Such separate compilation is especially important in large programs, where to compile a full program could take a hour or more. No one wanted to wait that long to fix one small change to one small part of a program.

Separate compilation avoids this. Each program file containing definitions can be compiled into machine code by itself, with references to code found in other files finalized later through the linker. In C++ the header files with their declarations act as promises – that the definitions for the functions declared in the header file are available and will be found at link time.

Separate compilation does, however, make the whole process more complex. Because one file may or may not depend on other files, it is not always clear to the compiler what should be re-compiled. The traditional approach involved what are called 'make' files in which the programmer explicitly stated what files depended on what other files. Using this information, the compiler would re-compile a given file only if that file itself had been changed (based on the date and time of the file on disk) or if one of the files it depended on had been changed.

More recently, easier to use, more automated approaches have surfaced. Using a windows-mouse interface (often called a Graphical User Interface or GUI), the programmer defines the dependencies with very little typing. The dependencies may be displayed via a simple indenting scheme, making it easy for the programmer to visualize the dependencies. Such tools also allow the programmer to compile the same code for 'DOS' or 'Windows' and for 16 or 32 bit systems. You are urged to check the manual for your programming environment to determine the easiest way to perform separate compilation, etc. on your own system. (Borland C++, for example, allows programmers to use what are called projects. The general instructions for working with projects in Borland can be found in the document "BorlandProject.htm" )

Top of Section

Main Menu

Next Section