Instructor's Manual

Computing Fundamentals with C+
Object-Oriented Programming and Design, 2nd Edition
Rick Mercer
Franklin, Beedle and Associates, 1999


 









Student using this Textbook

http://www.cs.arizona.edu/people/mercer/compfun2/ is the url for the home page for student support material for Rick's intro C++ textbook. This home page stores:

For Instructors Only

An Instructor's CDROM is available for instructors who adopt this textbook. Since the CDROM has all exercise answers, solutions to all programming projects, and actual quizzes and tests (with answers), the CDROM is only available to instructors who have adopted this as a required textbook. The CDROM also has all the MS Powerpoint presentations, and source code files that is available from the web site. You can download the Microsoft Powerpoint viewer for free from here.



In this Document:

A) What's up with the compilers?

B) Ways to use this Textbook

C) Instructors Manual on CDRom   for instructors only

D) Chapter by Chapter Report   Prerequisites, goals, and experiences for each chapter

  1. Analysis and Design
  2. Implementation
  3. Function Calls and Headings
  4. Messages
  5. Functions and Parameters
  6. Class Definitions and Member Functions
  7. Selection
  8. Repetition
  9. Files
  10. Vectors
  11. A Container Class with Iterators
  12. OO Software Development—Analysis and Design
  13. OO Software Development—Design and Implementation
  14. A Little Indirection, Pointers, Containers, and Iterators
  15. Dynamic Memory Management
  16. OO Software Development—Inheritance and Polymorphism
  17. Templates
  18. Operator Overloading
  19. Doubly Subscripted Objects, Matrix Objects
  20. Recursion


A) What's up with the compilers?

The book was written to be compliant to the C++ ANSI/ISO standard. However, at the time of this writing, compiler vendors are complying to the standard in different degrees. This makes things very frustrating. What might work on one C++ compiler may not work with another. Eventually this will hopefully be a thing of the past.

One problem is in the use of .h in the includes and the use of using namespace std;. If these do not work on your system, simply use #include<iostream.h> rather than #include<iostream>. You also will not likely be able to write using namespace std;. You can actually use Borland 4.52 with my files and a few tricks that work on this particular system to make an older compiler look standard (you could get the stl to carry this out even further). Also, older compilers do not implement the bool type. You can define true and false as 1 and 0, respectively, or simply #include "bool" (assuming you have copied the file named bool into your working directory/folder).

Here are some general comments concerning the files I have tested on three major platforms. It is a subset of all available compilers, so you may have to make adjustments for your system if you do not have a compiler that is up to the standard.  Please let me know if things change with your compiler, or if my files are not working on your compiler mercer@cs.arizona.edu

The following compilers are very close to standard. If you have one of these, or some other standard compiler, use the book as is and the Standard #include files as they are.

The following compilers can be used with the files available at this textbook's web site so they appear to be close to the standard. The files for each compiler were tested with the given system:

B) Ways to Use this Textbook

There are several paths you could take through this textbook. The following table indicates three paths that were actually used during iterations #1 through #6 (Spring 1996 through Spring 1998) while I was developing the second edition.

It should be noted that I always used computer projection to display the presentation slides found at this textbook's web site (and also on the Instructor's CD Rom). This saves students from taking all but a minimum of notes during lecture. My students either 1) purchase from the copy center or 2) are given, hard copy versions of these lecture presentations. This allows more time for thinking during lecture and writing of useful (rather than pedantic) lecture notes.

Also notice that the textbook has the built-in flexibility to skip classes and serve up a procedural approach that uses existing objects. Simply skip Chapter 6: Classes. If you skip Chapter 6, do not assign any programming project in Chapters 7 through 10 that is marked with (prerequisite: Chapter 6).
 
  How the author has used his textbook with three different audiences in a 15 week semester (time specified in weeks)

           *min/wk == minutes per week

Chapters

Computer  Science
4 credits

lecture: 
150 min/wk*
lab:
 100 min/wk

Engineering
Audience
3 credits

lecture:
100 min/wk*
lab:
  50 min/wk

General Audience
3 credits

lecture: 
100  min/wk*
lab:
50 min/wk

1 Analysis and Design 
1.0 week
1.0
1.5
2 Implementation 
1.0
1.5
2.0
3 Function Calls and Headings 
1.0
1.5
2.0
4 Messages 
0.5
1.0
1.5
5 Functions and Parameters
1.5
2.0
1.5 
6 Class Definitions and Member Functions
1.5 weeks
   
7 Selection 
1.5
2.0
2.0 
8 Repetition 
1.5
3.0
2.0
9 Files
0.5
 
0.5
10 Vectors 
1.5
2.0
2.0
11 A Container Class with Iterators
0.5
   
12 OO Software Development—Analysis and Design 
1.0
   
13 OO Software Development—Design and Implementation 
1.0
   
14 A Little Indirection, Pointers, Containers, and Iterators
CS2
   
15 Dynamic Memory Management
CS2
   
16 OO Software Development—Inheritance and Polymorphism
CS2
   
17 Templates 
CS2
   
18 Operator Overloading
CS2
   
19 Doubly Subscripted Objects, Matrix Objects
0.5
1.0
 
20 Recursion
0.5
   

An objects-early approach would use the core chapters in this order: 1, 2, 3, 4, 5, 6, 7, 8, 10, and 11 (Chapter 11 is a summary of vectors and classes so Chapter 11 could be considered a review of Chapters 6 through 10 or as part of a final exam preview).

The textbook was designed to allow the flexibility to present classes early, late, or not at all. Even if you skip Chapter 6 on C++ classes, the following set of chapters could be chosen to fulfill the needs of your course after you have presented Chapter 10, "Vectors",

Chapter 17 (Templates) and Chapter 18 (Operator Overloading) require that you have presented either Chapter 6 and/or Chapters 12 and 13. Chapters 16 (Inheritance) should be read only after all preceding chapters (1-15).



C) Instructors Manual on CD Rom

The CDRom has the following folders:

\BookCode  All programs as they exist in the book (subfolders: Standard and NonStandard),
\ExerAns      Answers to all exercise from the end (or sometimes middle and end) of each chapter.
\Includes      Author supplied files (baccount, grid, compfun, and test drivers for programming projects )
\Lectures      MS Powerpoint Lecture Presentations. Each presentation is an outline of a book chapter.
\ProgSols     Answers to 144 of 149 end of chapter projects
\Test&Ans   A variety of tests with answers in separate files
 

\BookCode

\ExerAnsw
Answers to all exercises in the book. File formats include Word, rtf, and html. Please do not place the even numbered exercise answers on the Web (other instructors may be using them for tests and/or homework). I usually assign these exercises for the day of a test review and then show the answers during the test review. Unfortunately, not many people usually complete them. But those who do complete them do benefit. The other students try to copy answers, but they don't usually have the time to write all answers. I do this to encourage students to do homework and think about the test before the test reviews.
\Includes
This folder contains files that were tested with standard compilers and several older compilers. It is not an attempt to cover all compilers, but these files did work on several major platforms as indicated in parentheses.
\Lectures
Each chapter is outlined in MS Powerpoint. Files are named mercer01.ppt for Chapter 1 through mercer20.ppt for Chapter 20. These slides occasionally refer to optional demo programs. If you want to run them, you will need the files in the subfolder \Lecture\DemoProg. I left a few files named 01-bw.ppt through 07-bw.ppt. You might want to compare these in your specific light environment. The bw (black on white) presentations look better when the screen is in brighter light. They don't look as washed out when you can't dim the front lights that are washing the screen (maybe it is just the rooms I teach in) . The mercer01.ppt through mercer20.ppt files look better when the screen is in a darker light condition.
\ProgSols
This folder contains subfolders named Ch01 through Ch20. All but two of the chapter project solutions (153 of 155) are provided (12C and 13C are missing on purpose, and I pulled 12D and 13D from the 3rd printing).  Please do not make these program solutions available on the Web or to any of your students. If they get out into the open, someone might find a way to make money selling these solutions to the benefit of no one but cheaters.
\Test&Ans
All tests are in Microsoft Word 97 only. I am not trying to offend those who use other editors. It just so happened that this was the format I used to create the tests. MS Word is also a popular word processer. I hope you can convert these files into your favorite editor.

This folders contains tests and quizzes listed by chapter. Some files have test questions for two or more chapters while others have questions for only one chapter. The files with questions for shorter quizzes on only one chapter contain the word Quiz.

The following two special files might prove useful in constructing other tests, quizzes, and scan form tests.

001-19ScanTest.doc   -- Multiple choice and T/F (close to a scan from Final Exam I once gave in edition #1)
001-20-Exercises.doc -- All exercises questions from the book (Caution: Answers to odds are on the Web)

Otherwise, the tests and quizzes and the answers to the tests and quizzes (beginning with Answ ) are stored in files that are named to describe the chapters they are about.  Here are a few examples:

02_3_4.doc           --  Answ02_3_4.doc         Test on Chapters 2, 3, and 4
08_10.doc            --  Answ08_10.doc          Test on Chapters 8 and 10 only (no 9)
09Quiz.doc           --  Answ09Quiz.doc         Quiz in chapter 9 (ifstream) only
05_07_08_dot1_A.doc  --  Answ05_07_08_dot1_A.doc Test on Chapters 5, 7, and section 8.1
05_07_08_dot1_B.doc  --  Answ05_07_08_dot1_B.doc Test on Chapters 5, 7, and section 8.1 (2nd form)
06Quiz.doc           --  Answ06Quiz.doc         Chapter 6 questions for a quiz
10.doc               --  Answ10.doc             50-minute test on chapter 10, 1-D arrays
19BQuiz.doc          --  Answ19BQuiz.doc        Chapter 19 quiz only (B means 2nd form)

I never did have ask very many test questions for Chapters 12, 13, and 16, so there are no tests or quizzes for those three chapters.

FYI (No guarantees) I use the following formula to see how long the test will take students. I don't know if this will help you or give false time estimates, so please take it with a grain of salt):

  Time it takes me to answer the test * 4  == when approximately one third of students will be done
  Time it takes me to answer the test * 5  == when approximately two thirds of the students will be done

For a fifty minute test, I like to be able to write the answers out in about 10 or 11 minutes (reading the questions, writing very quickly, and not checking answers). For example, when it takes me 10 minutes to write the answers to the test that I wrote:

40 minutes: About 25% of the students are complete
50 minutes: about 85% of the students are done
55 minutes: I collect the test and 1% to 5% claim they need more time

Only about 10% of my students do not complete all questions because I usually grant an extra 5 to 10 minutes whenever it is possible (when no one kicks me out because they have the room after us). Unprepared students may not finish some of the provided tests within 50 minutes. If this is not desirable, consider chopping off a question or two. Some of the tests were given during 75 minutes lectures, so please do not assume every test on the Instructor CD will work in a fifty minute setting. For the 75 minute lectures. I try for a test that takes me 15-16 minutes to answer the questions (reading questions, writing quickly, and not checking answers). Your times may vary.

Also, some of the test questions are from my first year at the University of Arizona where we use Java. I believe I correctly translated  the questions into C++. However, I did not class test every test in a C++ setting. These tests are provided on an as-is basis even though some are really quite good 50 minute tests. Some questions are way too easy and some are way too difficult. I usually end up with an mean of 75% and median of 80%. Ranges are are somewhere around 15% to 100%. I usually have 1% to 3% of my students get 100% at both Penn State and the University of Arizona.



D) Chapter by Chapter Reports

Prerequisites, Goals, and Experiences for Each Chapter
 

Chapter 1: Analysis and Design

Prerequisites:

None

Goals:

  1. Show one example of program development: analysis, design, and implementation as the case study to support a simplified program development strategy of analysis, design, and implementation
  2. Let students do something before getting on a computer
  3. Introduce the Input/Process/Output Algorithmic Pattern
Experiences:

Chapter 1 is easily presented in two 50-minute lectures using the presentations available with this instructor's manual. A closed lab or recitation could have students completing one or more of the Analysis and Design projects at the end of the chapter, or they could be assigned as homework.

Although int and double are implemented as true C++ classes, they can certainly be viewed as such. I have decided to treat the fundamental data types as classes and to use the term object instead of variable. Things will hopefully be smoother if you can accept these two assertions and try not to spend much time distinguishing between the two:

1. Object and variable are interchangeable terms.
2. Class and data type are interchangeable terms.
The Chapter 1 case study involves grade assessment. If you present material like this on a syllabus, especially a weighted average, consider using your syllabus and some sample data to generate a hypothetical grade. If you don't have a similar grade assessment policy, simply state that some schools do. The case study is the first example of an Input/Process/Output algorithm that the students can relate to.

Anecdote: On the first day of class, before students had a chance to read anything, I read the case study problem specification on page 5, I made this statement and asked this question before students:

An object is a thing that you can do something to.

Do you recognize any objects in the problem statement?

One student answered:

Numbers

I couldn't have hoped for a better response. I said we called them double objects or doubles for short. Named double because doubles store double the precision of floats. One student (a Navy trained nuclear power plant operator, now a systems analyst) asked if an object was the same thing as a variable. I said the terms are interchangeable. I added that for beginning students, it is easier to think of computer screens, bankAccounts, automated teller machines, transactions, automobiles, reservations, and so on as objects rather than variables. He contended it was easier to say variable. He earned an A anyway.

The case study was meant to be something that students can relate to or generalize to fit their own particular situations. The main motivation in Chapter 1 was to move away from the typical approach that presents a history of computer and attempts to get students to understand the inner workings of the computer and machine language. I have diverted from this to emphasize program development and that there is something more than coding. I also am trying to emphasize the fact that even the simplest of C++ programs are rich with objects: cout, cin, and the doubles that store floating-point numbers.

New to the second edition is a bit of emphasis on algorithmic patterns. The Input/Process/Output pattern has helped the novice programmer while providing a vocabulary for commenting on algorithm and programs that are wrong. "You did the process step for the input step", for example. This does happen.
 
 

Chapter 2: Implementation

Prerequisites:

Chapter 1

Goals:

  1. Teach the nuts of bolts of C++ programs: variable declaration, initialization, assignment, Input/Output, and arithmetic expressions
  2. Introduce the Prompt then Input pattern
  3. Let students practice implementing simple IPO algorithmic patterns
  4. Evaluate and write arithmetic expressions
Experiences:

I usually present this chapter in three 50-minute lectures using the presentations available with this instructor's manual.

This is the chapter that focuses on the details and syntax to complete simple programs. Students are shown that a program is a collection of tokens. They write arithmetic expressions. Combined with cin and cout, students should be able to write simple Input/Process/ Output programs. With a two hour closed lab, students can complete 2 to 4 programming projects depending on experience and the choice of project. The most difficult project is 2I: Combinations, perhaps because it doesn't look familiar to most. I usually only assign it when during an engineering service course.

Chapter 3: Function Calls and Headings

Prerequisites:

Chapters 1 and 2

Goals:

  1. Get students to use existing functions, whether they are global functions such as sqrt from cmath, decimals(cout,2) from compfun, or bankAccount::withdraw from baccount.h.
  2. Get students comfortable reading function heading, preconditions, postconditions,
  3. Do int quotient/remainder division with / %
Experiences:

I usually present this chapter in three 50-minute lectures using the presentations available with this instructor's manual.

Writing functions and understanding argument/parameter associations is one of the more difficult concepts students encounter—besides loops perhaps—in this first course. Students have trouble reading function headings, so future programming projects are written to help ease students to understanding a program as a collection of classes that are a collection of functions. Additional support came by presenting Chapter 6: "Class definitions and Member Functions" and assigning some projects that require students to implement member functions given the class definition. Many projects give the function headings and ask students to implement the function. Students become adept at implementing free functions and member function classes. And if you get to Chapters 12 and 13 on object-oriented analysis and design, students also experience designing classes instead of implementing them.

I believe using the terms argument (in the call) and parameter (in the function heading) serves our students better than the confusing terms actual parameters and formal parameters.

I delayed coverage of programming errors to the end of this chapter to allow students to actually experience them as they implement a few programs. This was intentional because earlier coverage had proved ineffective.

If you have computer projection, students appreciate demonstrations done with a source level debugger that shows line by line execution of statements. You can also show the types of errors and students can commiserate.

Chapter 4: Messages and Member Functions

I usually present this chapter in three 50-minute lectures using the presentations available with this instructor's manual.

This Chapter makes references to the programmer-defined classes grid and bankAccount. To complete some of the programming projects at the end of Chapter 4, students will need the files from their disk that accompanies the textbook or at this textbook's Web site site

http://www.cs.arizona.edu/people/mercer/compfun2/#Files

Prerequisites:

Chapters 1, 2, and 3

Goals

  1. Understand the relationship between objects and classes.
  2. Send messages
  3. Present an appreciation of why software is divvied up into classes and functions.
The following two author-supplied classes introduced in this chapter will be used later on to illustrate new concepts: 1. bankAccount
2. grid
3. string
Because of this, I recommend that you do not skip over these classes.

My students have an easy time with bankAccount objects. They can relate to bank accounts. Bank accounts make sense. They are not complicated. I got the idea from John Pugh in 1989 at an ACM/SIGCSE post-symposium workshop. BankAccount has become a canonical first example, please don’t feel ashamed (as some suggest) to use it just because it is often used as a first example. Your students will not feel slighted, even if they are working adults (at least that has been my experience teaching to freshman and to many adult section in continuing education classes). Students have little problem using these bankAccount objects.

You may skip the grid class completely. Because the grid class is almost self-explanatory, students could understand examples in upcoming chapters. However, I believe it is worth the ten minutes or so to present the grid class and then to assign a few programming projects related to grid (4F, 4G, 4H, 4I, or 4J). I usually ask them to complete any two from this set of five projects. You can even ask questions on tests if you supply the class definition or diagram, or if it is open book. I don't recommend making students memorizing grid messages.

The bankAccount will help when you teach students to implement their own classes. It doesn't have to be, but I use the bankAccount and grid classes to reinforce new topics later in the text. This is to avoid covering a new class for each new major topic. Future references will be made to class bankAccount and grid.

The string class is fairly easy too. Students do not seem to have little trouble with 0 being the index of character #1 in a string. Some do get confused because length returns the number of characters when they think it should return the number of characters - 1. String looks and acts like other primitive types such as int and double , except now you can send messages to string objects such as length.

The zero-based array indexing of string and grid cause little if any problem to students at this point. The big pay off comes when you present singly and doubly subscripted arrays—the vector (Chapter 10) and matrix classes (Chapter 19).
 

Chapter 5: Functions and Parameters

Prerequisites:

Chapters 1, 2, 3, and 4

Goals:

  1. Get students writing free (non-member) functions
  2. Appreciate why software is structured into functions communicating via argument/parameter associations and returns
  3. Revisit the importance of testing
  4. Use test drivers to help implement and test free functions
  5. Get a first exposure to scope rules while accepting that this is a subject that will be revisited in upcoming chapters
Experiences:

I usually present this chapter in three 50-minute lectures using the presentations available with this instructor's manual.

Students can implement functions and usually do well on tests with questions that begin like this:

"Write a function named foo that...."

It helps to let students know that many programming projects include test drivers and to stress that they exist only for testing purposes. These functions are meant to be parts of larger systems and they should be thoroughly tested before they become part of
 

Chapter 6: Class Definitions and Member Functions

Prerequisites:

Chapters 1, 2, 3, 4, and 5

Goals:

  1. Get students reading class definitions (and more practice reading function headings)
  2. Present an object pattern that could be applied to all classes up through Chapter 8
  3. Discuss some class design issues (public versus private; selecting members)
  4. Formally cover the C++ class, students implement member function given the class definition.
  5. Discuss the role of constructors, accessors, modifiers and how to implement them
Experiences:

I usually present this chapter in four or five 50-minute lectures using the presentations available with this instructor's manual.

In the first part of this chapter, students are asked to read class definitions. The first set of programming projects asks them to use an existing class known only be the class definition I used a class named weeklyEmp, but feel free to use your own class. I do this in so student can see the relationship between message signatures (the function heading in the class definitions) and the legal messages to those member functions.

Students are then asked to implement member functions given the class definitions and/or to add some member functions. I ask them to complete 6D, 6E, and them 6F. Students can get these pretty easily, especially if they have implemented several free functions (Chapter 5). By this time, students have a good grasp of using other classes and implementing functions, both free and member.

Chapter 7: Selection

Prerequisites:

Chapters 1, 2, 3, 4, and 5 (if you skip 6, don't assign projects marked with a 6 prerequisite)

Goals:

  1. Learn selection control
  2. Consider more algorithmic patterns such as guarded action and alternate selection.
  3. Implement algorithms using if, if…else, and nested if…else
  4. See multiple returns
  5. Practice branch and boundary testing and use larger test drivers.
Experiences:

I usually present this chapter in four or five 50-minute lectures using the presentations available with this instructor's manual.

The if...else statement is an easy topic for students. I usually just mention the switch statement as an excuse to introduce the integral type char. It seems like most people either really like switch or don't use it at all.

It is a bit awkward to talk about nested logic but then later provides the option of multiple returns from a function. So we can get code like this even though we don't need the else's

string letterGrade(double percentage)
{
  if(percentage >= 93)
    return "A";
  else if(percentage >= 90)
    return "A-";
  else if(percentage >= 87)
    return "B+";
  else if(percentage >= 83)
    return "B"

  // ...

}

Actually, students had no problems with multiple returns. Instead some students still have problems with the function heading (parameters) and placement of functions in the proper location in the file (in relation to the main function). So in this second edition I have supplied function headings in some of the first programming projects.

The idea of writing parameters caused trouble for some. Others placed the heading in strange places and the body elsewhere. Students like to put a semicolon at the end of the heading and then have trouble trying to figure out the error messages in code like this

double max(double x, double y);
{
  //...
}

Have students review the Chapter 5 and 6 Programming Tips beginning on page 165 and 226, respectively.

Using the familiar classes of grid and bankAccount to introduce new concepts saved the overhead of introducing new classes with new concepts.
 

Chapter 8 : Repetition

Prerequisites:

Chapters 1, 2, 3, 4, 5, and 7 (if you skipped Chapter 6, don't assign projects marked with a Chapter 6 prerequisite)

Goals:

  1. To develop programming skills of repetition (while, for and do while loops)
  2. Distinguish between determinate and indeterminate loops
  3. Experience nested repetition
Experiences:

I usually expend six fifty-minute (or four 75-minute) lectures to present repetition. This is probably the most difficult topic that students encounter to this point. I have found presenting determinate loops with the for statement first increases the effectiveness of lecture and student time. Talking about non-determinate loops becomes easier and students are better prepared to implement while loops, especially if you use the while-true idiom (see below).

I recommend that you tell students to write sentinel loops like this

while((cin >> x) && (x != -1))
{
    // process x
}

With this, students don't have to worry about the priming cin input. I also encourage you to use the following loop pattern.

while(true)
{
    … do whatever
  if( it's time to exit the loop )
    break;
    … do whatever
}

Although this idiom has its critics, it provides a much easier pattern that matches the problem. The controversy may simply well extend from the fact that Pascal does not directly support this loop-and-a half pattern whereas Ada does (with loop and exit when) and C++ and Java use break.

Chapter 8 is still quite long. I felt it desirable to cover the three major repetition control structures (while, for, and do while) in the same chapter. However, coverage of the do loop could be skipped.

Using the familiar classes of grid and bankAccount to introduce new concepts saved the overhead of introducing new classes with new concepts.
 

Chapter 9: File Streams

Prerequisites:

Chapters 1, 2, 3, 4, 5, 7, and 8

Goals:

I usually present this chapter in one 50-minute lecture using the presentations available with this instructor's manual.

This very short chapter used to be just one section in a repetition chapter. Reading until end of file introduces another known use of the indeterminate loop pattern. It also allows subsequent classes to read input from file for programs requiring large amounts of output.

Even though ofstream objects are mentioned, I usually skip it because the other 98% of the time, students see output going to the screen. You certainly could use file output if you wanted to. It's just that I don't use it elsewhere in the book.

Be careful with some older compilers. They may not handle ifstream objects correctly. MSVC++ 4.0 has the nasty attribute of creating an empty file when a file is not found. This can be very frustrating because

if( ! inFile)

does not catch this error and the first attempt at file input fails because the file is empty.

Again, using the input statement is an elegant way of reading until end of file.

while(inFile >> name >> hours >> rate )
{
   // use name hours and rate
}
 
 

Chapter 10: Vectors

Prerequisites:

Chapters 1, 2, 3, 4, 5, 7, and 8 (if you skipped Chapter 6, don't assign projects marked with a Chapter 6 prerequisite. If you skipped Chapter 9 on files, skip section 10.3.1: Initializing a vector of Objects with File Input—or briefly discuss ifstream at this point)

Goals:

  1. Introduce vectors as object that stores a collection of objects.
  2. Demonstrate encapsulation and how to hide vector procession inside C++ classes.
  3. Present sequential search and a simple O(n2) sorting algorithm (selection sort).
  4. Demonstrate binary search and indicate that it is more efficient than sequential search by comparing O(log n) and O(n).
Experiences:

I strongly urge you to use a safe vector like the one that comes with this textbook (described below).

I usually present this chapter in three 50-minute lectures using the presentations available with this instructor's manual. I usually use one more lecture to introduce sorting with the selection sort algorithm and perhaps binary search. I'll use part of a lecture as a review and practice quiz as vectors with the subscript operator [] can be difficult for some students.

The zero-based array subscripting introduced with string and grid (the first row and column are referenced as zero, not one) really help a lot.

It really helps to draw a picture of a vector that looks like this:

The state of x after assigning values to the first five elements after this construction:

vector <double> x (8, -1.0); // x.capacity()==8, all elements == -1.0
 
x[0]
2.6
x[1]
5.7
x[2]
8.3
x[3]
9.9
x[4]
5.1
x[5]
-1.0
x[6]
-1.0
x[7]
-1.0

Stress that a vector's main purpose is to store a collection of objects, where these elements are all of the came class. We would write subscripts if keyboards allowed us to.

USE A SAFE VECTOR

Students are much better off using a vector class with subscript range checking. Unfortunately, the standard vector class does not perform this important-to-new-programmers check for efficiency reasons. The best way to get it is to have you lab set up to look for this textbook's vector class. The include path should be set to look for this textbooks safe vector first. How this is done varies between vendors and environments.
 
 

Chapter 11: A Container With Iterators

Prerequisites:

Chapters 1, 2, 3, 4, 5, 6 7, 8, and the first part of 10. Chapter 11 discusses vector processing algorithms within a class. Therefore, Chapter 6 must be presented first. You could present chapter 6 anytime, including now.

Goals

Let students practice:

  1. Implementing Classes
  2. Use of arrays to store a collection of objects: add to and remove from
  3. Use the iterator pattern to traverse a collection of element without revealing the underlying implementation
Experiences
 

This Chapter provides a summary of class definitions and array processing while introducing the notion of container classes, an important topic in most follow up courses. I am sometimes lucky to get this far in one semester. However I have occasionally managed to present this chapter as a summary of classes and arrays and as a prerequisite to the object-oriented design chapters (12 and 13).

This short chapter at one time was two section of chapter 10. This 13 page chapter could be presented in one 50 minute lecture. It is a nice summary of classes and arrays.

The iterator pattern is kept intentionally simple, but it also acts as preview of the CS2 course.

If you don't like the word bag, you could use the term multi-set to describe this container. I borrowed bag from the Smalltalk library, but multi-set works also.

It is nice to begin the 15th week with this chapter. A good final exam question then is to have students implement — in whole or in part — a set class.

I thought about waiting until templates before talking about container classes, but this seemed like a good time to introduce the C++ typedef. Placing typedef at the top of files also brings a cheap and easy form of genericity, especially when it means students can learn more about arrays and classes without the syntactic overhead of C++ templates.

The notion of a maximum capacity could have been avoided with a vector. I used the primitive array so you can ask students to perhaps grow and/or shrink the array whenever necessary.
 

Chapter 12: Object-Oriented Software Development
Analysis and Design

Prerequisites:

All of Chapters 1-11 except the second part of 10: Binary Search and Selection sort. Chapter 11 helps because the iterator pattern is applied to class CD and class cdCollection.

Goals

This chapter analysis and designs a system by partitioning that system into objects. It is presented in the context of a real world problem—building a cashless jukebox system for the student center. The analysis of this chapter will help the programming team design the class definitions and implement the member functions in the chapter that follows. Student experience the following

  1. Identify classes that model a solution to the problem.
  2. Assign responsibilities to classes.
  3. Visualize interactions among the classes.
  4. Use Component/Responsibility/Helper cards to capture analysis and design decisions.
  5. Understand the need for analysis and design before implementation.
Experiences

This chapter and the next (Chapter 13) are a nice capstone to a first course. When everything went well, I presented the material in this chapter and the next, let students experience working on teams, and collected a design project (CRH cards, role playing, and compiled .h files, but no implementation). All this went on while students worked on individual programming projects dealing with arrays.

However, I have found it best to start our second course with these chapters. These two chapters provide a nice review of object-oriented thinking and allow students to implement part of a bigger system. At the same time, students analyze, design, and implement an entirely different system from scratch.

For the most part, this is a true story. The names are real except I used Chelsea as a pseudonym for myself.

Here are some things I wish I hadn't done:

  1. I should have stuck with CRC. Although the term Collaborator was used instead of the original term Helper, CRC is the accepted term, for better or worse. I changed it to Helper after a workshop a SIGCSE 98 when the term collaborator caused a lot of confusion and helper made more sense to the teachers present. As was suggested: "Collaborator implies a two-way relationship, but it seems like you mean a one-way relationship—one class helps the other fulfill its responsibility"
  2. I wish I hadn't used the term object expert. There was no "expert" around. Only a teacher who felt he knew enough to guide students through a relatively simple, in-the-domain-of-students system. I currently have undergraduate teaching assistants with no background in object-oriented design facilitating in our weekly recitations. The analysis and design activities can be guided by common sense and establishing a common vocabulary. So to this I say
No Experts Required
























Suggestions for grading team projects of Chapter 12

You can evaluate student's design (12A, 12B, 12C, or 12D) like this:

  1. Meet with each team and ask them to role play a few easy and a few exceptional scenarios. Ask the team some modification exercises A grade (I used from 1 to 5) is based on how well they understand the system and how easily it is to modify the design. The fewer changes the better.
  2. Collect their CRC cards and picture of the system. Grade it according to how well they have documented their understanding of the system and the design decisions they made. Some CRC card sets and pictures will be outstanding. Others will be poor. You'll get some in-between.
It is difficult to do face to face grading like this in large classes, so you could just collect the card sets and pictures. More objective grading on design comes in when they hand in the class definitions (.h files) that compile. Some capture a design fairly completely—others are hacks. This is subjective grading.
 
 

Chapter 13: Object-Oriented Software Development
Design and Implementation

Prerequisites:

All previous Chapters 1-13

Goals

This Chapter is about translating the CRH (CRC) cards into C++ class definitions. At this level, there is a mapping of the analysis deliverable—a set of CRC cards—to C++ class definitions:

  1. Action responsibilities become public member functions headings in a .h file
  2. Knowledge responsibilities become private data members in a .h file
  3. Constructors can then be added to initialize the data that is either accessed by accessors or modified by modifiers.
Experiences

Students have a chance to see how work can be divided up amongst team members and how to individually test classes. This is a chance to see how previously acquired programming skills are put to use in the context of a relatively large system.

Many students confuse the user with the software version of the user in the system. Although the real-world objects are modeled in software, it helps to suggest they are distinct. Use the phrases, software version and real world version often (or something analogous).

Objects with an int, a double, and a string are not very interesting. Now students get to see a design that has a class with very interesting objects such cardReader, CDCollection, and trackSelector. And they can run this system. However, instead of actually playing songs, a simulation mode can be obtained by printing the play list captured after several students selected one or two songs a piece (Note: Have teams hand in disk for this project).

I have used other examples that are just figments of imaginations. Now students are part of something that actually works. The whole project has more meaning now that anyone can select a song, and have that song actually play on my office stereo system (okay, if I have fresh batteries). If I have time, I would like to move from the current system that sends IR signals to a small capacity CD player. With some money and time, I could upgrade to 300 CD player and a device that communicates with a more reliable direct connection. Then I could read the CDs in the CD player and go out to the internet and initialize the CD Titles, Artists and all tracks without having to rely on the accuracy of a text file.

By following along with this project in the book and presentation slides, students have been given guidance in how to analyze, design, and implement another system from scratch. Experience has shown that students can implement any of these systems listed on page 516:

Note: I let teams pick a project (or one of their own choosing), but I have never had any students select Checkbook application.

Suggestions for grading team projects of Chapter 13

The deliverable is a working system, so you could use familiar grading criteria based on the files handed in.
 
 

Chapter 14: A Little Indirection

Pointers, Containers, and Iteraters

Prerequisites:

Chapters 1-11. You don't need chapters 12 and 13 before this.

Goals:

  1. Introduce pointer objects that store addresses of other objects.
  2. Introduce the standard (stl) list class and iterator objects
  3. Show how standard iterator objects are used to implement the iterator pattern
  4. Provide the concepts and syntax related to C++ implementation of inheritance (could skip 15)
Experiences:

This chapter used to be combined with the material in Chapter 15, but was split into two chapters for two reasons. 1) It got too long when I added the standard list class and a linked list. 2) This also allows you to present Chapter 14 as the only introduction necessary to present Chapter 16 on Inheritance. I thought it would be easier to skip a chapter rather than a few sections in a chapter.

It is so nice to finally have standard container libraries in C++. I don't attempt to present all of the stl classes or generic programming, but you can use one of the standard classes anytime you need one without implementing them. It helps to strike a balance between implementing data structures, using them in programs, and just plain understanding them.
 
 

Chapter 15: Dynamic Memory Management

Prerequisites:

Chapters 1-11 and 14. You don't need chapters 12 and 13 before this.

Goals:

  1. Finally introduce char* objects.
  2. Show benefits of dynamic memory allocation techniques. How it is used with string objects.
  3. Demonstrate the need for copy constructors and destructors
  4. Understand a collection stored as a linked list.
  5. Introduce the C struct
Experiences:

I was pleased to find that students understood the purpose of new and delete. Using the now familiar string class implementation saved the overhead of introducing a new class for which the use of new and delete made sense. I use the textbook's string class as an example since it is much easier to understand (although not near as useful) as the standard templated basic_string class. The simple linked list class also provides a context in which dynamic memory allocation makes sense.

Copy constructors are not easy to understand. Even though they are not necessary for implementing classes that dynamically allocate memory.

Destructors are more logically covered after the delete operator. Destructors often use the delete operator to plug one source of memory leaks.

I usually soft pedal operator overloading. Just knowing it can be done seems to suffice. If you want to go into more detail with operator overloading, present Chapter 18: "Operator Overloading".

You should warn students that this list class is kept intentionally simple (few operations). They can expect more operations in other lists.

You might also consider warning students that a list is an abstract data type. When they later see linked lists they should realize that the linked list is but one implementation of list. Unfortunately, lists have become synonymous with linked lists.
 
 

Chapter 16: Object-Oriented Software Development

Inheritance and Polymorphism

Prerequisites:

Chapter 1 - 14 You don’t need chapter 15

Goals:

This chapter uses a team-based approach to introduce the two other major features of the object-oriented paradigm:

This chapter also demonstrates Experiences:

The case study presents another object-oriented approach to software development. I believe the inheritance relationship between classes is more easily understood in the context of a real example that makes sense. I suggest you avoid examples like: insects-winged-wingless, animals-dogs, and planes-trains-automobiles.

Consider this design heuristic related to inheritance

This is a good place to start. Define the common behavior and data.

Most people discover generalization easily, inheritance can come after the need for it is discovered.

In my 1991 Book, I implemented a Date class in Turbo Pascal. It was easier to borrow (with permission), Owen Astrachan's nice Date class. It is included with the book's disk and is avaialble at this book's web site.
 
 

Chapter 17: Templates

Prerequisites:

Chapters 1-11, 14 and 15. You don't need chapters 12 and 13 before this.

Goals:

Show how the C++ template mechanism implements vector and other containers that can store collections of any class of objects. This chapter demonstrates related implementation issues using template examples of the vector and bag classes of Chapters 10 and 11.

bag < book > myBookBag; // A bag that holds book objects
bag < CD > myCDs; // A bag that holds CD objects
Experiences:

It proved easier to use function templates before class template. At that point, genericity is pretty straightforward.

I often try to reuse previous examples to avoid having to introduce a new class each time. For example, the templated bag class was introduce in Chapter 11 so there is no reason to explain the bag methods or the iterator pattern again.

I have only covered the class templates once, and as the last topic in a course for students with one semester of programming. Students easily completed the programming project in which they implement a generic stack class. However, the labs provide much of the code.

The syntax for class templates is not intuitive.  It might be better to implement the member functions inside the class definition in one file. In fact, I do that wirh several generic collection classes.
 
 

Chapter 18: Operator Overloading

Prerequisites:

Chapters 1-11 and you'll also need 14and 15 for Section 18.3, "Overloading = for classes with pointer members"

Goals:

Experiences

For better or worse, operator overloading is necessary if you want a class to be stored in any stl class such as list. Although you should only have to implement < and ==, and include some function templates that define the other six based on these two, I found it much easier to simply implement all six. At the time of the writing, most systems weren't capable of the shorter approach. And besides, implementing all six makes more sense.

The complex class is redundant since the stl has a complex class, but it is a nice application of operator overloading that was relevant enough to be included in the standard library. I used it in my classes with engineers because electrical engineers are use complex numbers a lot.
 
 

Chapter 19 Double Subscripted matrix Objects

Prerequisites:

Chapters 1-10. 2-D arrays could be presented immediately after chapter 9: arrays

Goals:

  1. Introduce a "safe" generic 2-dimensional array class.
  2. Show simple examples of array processing: row by row, and column by column.
  3. Show that the primitive C array may have two or more subscripts.
Experiences:

Students had little trouble with this chapter.

The magic square programming project (11D) was popular, even though it was challenging. I believe that without the matrix class, the magic square problem would have been much more difficult.

I usually skip the case study on the visibility study because of time considerations. However, it was a real-life environmental research project and an application of processing "tabular" data.
 
 

Chapter 20: Recursion

Prerequisites:

Chapters 1-8 only. Implement functions and understand repetition

Goals:

  1. Examine how it is possible to use recursive calls as a valid programming technique to solve certain problems.
  2. Compare iterative solution to recursive solutions
  3. Identify the recursive case and the base (or simple) case in a recursive algorithm
  4. Implement recursive functions
Experiences:

I usually present this chapter before covering trees with a CS2 book.

Section 20.1 could be presented after chapter 7 as a brief diversion into recursion.