Practical C++ Programming by manish baranwal

programs.

In this chapter we try to introduce students to the entire software life cycle. One of the limitations of the

classroom is that the life cycle of a program is about a week long. The student gets his assignment, does

it, turns it in, and never touches it again.

In the real world programs stay around for much longer. Programs can easily remain around for years.

There are also a number of things you must do to create a program, other than writing the program.

These include the specification, the design, and the revision process.

We then take the students through a sample of the programming process using a simple calculator.

Very simple debugging is introduced. This consists of putting diagnostic std::cout statements in strategic

places throughout the program. One trick I use is to put “##” at the beginning of each diagnostic

statement. It makes it easy to spot the diagnostic output. In addition when we find the problem, it’s easy

to go through the program with the editor and delete all the ## statements.

Most programmers don’t actually create new programs. Most programmers revise and update existing

programs. Most of these programs are poorly commented if they are commented at all. Thus we have a

section on Electronic Archaeology, the art of digging through someone else’s code to figure out amazing

things, such as what the heck the code does.

Live Demonstration

Slide 19 calc3/calc3.cpp

Slide 27 guess/bad.cpp

Slide 28 guess/good.cpp

Classroom Presentation Suggestions

When presenting the first slides you might want to relate it to some of the programs you’ve written.

There are five slides for different versions of the Makefile. You will need to select the one appropriate

for your class.

Note: I suggest that you require your students to include a “Specification” and “Test Plan” for all

Page 21

assignments from this point on.

After the students see the slide containing the debugging output (Slide 17), put up the prototype (Slide 8)

and let the students spot the problem.

Again, we emphasize the difference between = and ==. This is the most common mistake people make

and one of the most difficult to detect.

The section on Electronic Archaeology is designed to teach the students how to go through strange code.

A typical program is presented on Slide 79. Try running it. See what it does. Let the students go through

it and try to figure out what is going on. Mark up the slide and add comments describing what the

students discover.

Note: Anyone who uses lowercase L (l) or uppercase O (O) as a variable name should be shot. It’s very

hard to tell the difference between the letter “l” and the number “1.” Also the letter “O” looks a lot like

the number “0.”