|
|
 |
|
|
|
|
65: {
66: case 0: break;
67: case 1:
68: pCondition = new Normal;
69: delete pCondition;
70: break;
71: case 2:
72: pCondition = new FireAlarm;
73: delete pCondition;
74: break;
75: default:
76: pCondition = new Error;
77: delete pCondition;
78: okay = 0;
79: break;
80: }
81: }
82: return 0;
83: } |
|
|
|
|
|
|
|
|
(0)Quit (1)Normal (2)Fire: 1
Logging normal conditions
(0)Quit (1)Normal (2)Fire: 2
General Alarm log
Warning!
Logging fire call.
(0)Quit (1)Normal (2)Fire |
|
|
|
|
|
|
|
|
Analysis: The simple loop created on lines 5981 allows the user to enter input simulating a normal report from a sensor and a report of a fire. Note that the effect of this report is to spawn a Condition object whose constructor calls various member functions. |
|
|
|
|
|
|
|
|
Calling virtual member functions from a constructor can cause confusing results if you are not mindful of the order of construction of objects. For example, when the FireAlarm object is created on line 72, the order of construction is Condition, Alarm, FireAlarm. The Alarm constructor calls Log, but it is Alarm's Log() that is invoked, not FireAlarm's despite Log() being declared virtual. This is because at the time Alarm's constructor runs, there is no FireAlarm object. Later, when FireAlarm itself is constructed, its constructor calls Log() again, and this time FireAlarm::Log() is called. |
|
|
|
|
|
|
|
|
Here's another problem on which to practice your object-oriented analysis: You have been hired by Acme Software, Inc., to start a new software project and to hire a team of C++ programmers to implement your program. Jim Grandiose, vice-president of New |
|
|
|
|
|