lafore_robert_objectoriented_programming_in_c

4.Is there is a down floor request on this floor, and we are going down, load the passengers.

5.If there are no destinations or requests above or below, stop.

6.If there are destinations above us, go up.

7.If there are destinations below us, go down.

8.If we’re stopped or going up, and there is a floor request above us, and there are no other cars going up between us and the request, or above it and going down and closer than we are, go up.

9.If we’re stopped or going down, and there is a floor request below us, and there are no other cars going down between us and the request, or below it and going up and closer than we are, go down.

10.If no other rules apply, stop.

Rules 8 and 9 are rather complicated. They attempt to keep two or more cars from rushing to answer the same floor request. However, the results are not perfect. In some situations cars are slow to answer requests because they are afraid another car is on its way, when in fact the other car is answering a different floor request. The program’s strategy could be improved by allowing the decide() function to distinguish between up and down requests when it checks whether there are requests above or below the current car. However, this would further complicate decide(), which is already long enough. We’ll leave such refinements to you.

State Diagram for the ELEV Program

We introduced UML state diagrams in Chapter 10, “Pointers.” Now let’s look at a state diagram for an elevator object. To simplify things a little, we’ll assume that there is only one person in the building and only one elevator in use. Thus there can be only one floor request at a time, and only one destination selected by the rider. The elevator car doesn’t need to worry about what the other cars are doing. Figure 13.6 shows how this looks.

In the diagram, “cd” stands for car destination, the button pushed inside the car, roughly corresponding to a value in the destination array in the program. Also, “fr” stands for floor request, the button pushed outside the car, corresponding to the floor_req variable.

The states are derived from the values of the current_dir variable plus the status of the car’s loading_timer and unloading_timer. Because all the transitions are the result of time ticks, only the guard conditions are shown. The guards represent what the car finds out about floor requests and car destinations.

13

PROGRAMS MULTIFILE

Questions

Answers to these questions can be found in Appendix G.

1.Breaking a program into several files is desirable because

a.some files don’t need to be recompiled each time.

b.a program can be divided functionally.

c.files can be marketed in object form.

d.different programmers can work on a different files.

2.An .H file is associated with a .CPP file using the ________.

3.An .OBJ file is attached to a .CPP file using ________.

4.A project file contains

a.the contents of the files in the project.

b.the dates of the files in the project.

c.instructions for compiling and linking.

d.definitions for C++ variables.

5.A group of related classes, supplied as a separate product, is often called a ________.

6.True or false: A header file may need to be accessed by more than one source file in a project.

7.The so-called private files of a class library

a.require a password.

b.can be accessed by friend functions.

c.help prevent code from being pirated.

d.may consist only of object code.

8.True or false: Class libraries can be more powerful than function libraries.

9.True or false: the interface is private and the implementation is public.

10.The public part of a class library usually contains

a.member function declarations.

b.member function definitions.

c.class declarations.

d.definitions of inline functions.

11.Two or more source files can be combined by ____________ them.

13

PROGRAMS MULTIFILE

22.To define a namespace you use a format similar to a class definition, but substitute the keyword ________ for class.

23.Using typedef allows you to

a.shorten long variable names.

b.substitute one type name for another.

c.shorten long function names.

d.substitute one class name for another.

Projects

Unfortunately, we don’t have room in this book for exercises that involve the kind of larger programs discussed in this chapter. However, here are some suggestions for projects you may wish to pursue on your own.

1.Create member functions to perform subtraction and division for the verylong class in the VERYLONG example. These should overload the - and / operators. Warning: There’s some work involved here. When you include subtraction, you must assume that any

verylong can be negative as well as positive. This complicates the addition and multiplication routines, which must do different things depending on the signs of the numbers.

To see one way to perform division, do a long-division example by hand and write down every step. Then incorporate these steps into a division member function. You’ll find that you need some comparisons, so you’ll need to write a comparison routine, among other things.

2.Rewrite the ELEV program so that it handles only one elevator. This will simplify things a great deal. Remove those parts of the program that aren’t necessary. Or you can assume there is only one elevator and also only one rider, as is done in the state diagram.

3.Modify the ELEV program to be more efficient in the way it handles requests. As an example of its current non-optimal behavior, start the program and make a down request on floor 20. Then make a down request on floor 10. Car 1 will immediately head up to 20, but car 2, which should head up to 10, waits until car 1 has passed 10 before starting. Modify decide() so this doesn’t happen.

4.Create a class library that models something you’re interested in. Create a main() or “client” program to test it. Market your class library and become rich and famous.

13

PROGRAMS MULTIFILE

Many template functions in memory

FIGURE 14.1

14

AND T

E EMPLATES

XCEPTIONS