UMBC CMSC202, Computer Science II, Fall 1998, Sections 0101, 0102, 0103, 0104

18. Even More Class Derivation

Tuesday November 03, 1998

Assigned Reading:  8.1-8.4 & 8.7

Handouts (available on-line):

Programs from this lecture:

• private derivation from Box Class
• GenStack derived from GenQ
• Pointers to derived objects

Topics Covered:

• In this lecture, we consider another kind of derivation, called a private derivation. (There is also a protected derivation, but we won't discuss it in detail.) As an example of private derivation, we will define a class called Package that is derived from our box class. Intuitively, think of a package as a cardboard box. We will allow a package to be placed inside another package using a member function called Store. If a package is stored inside another package, then the package inside must be smaller than the package outside. (This we can determine using the compare function.) The important part is that once we place a package inside another one, we do not want the package inside to grow or the package outside to shrink. Otherwise, the condition that packages are only stored inside larger packages is no longer true. Thus, we want to make sure that the member functions grow() and shrink() are not accessible through a package object. This can be achieved using a private derivation.

  Another way to think about this. In Lecture 16 we wanted to think of Cubes and ColorCubes as Boxes. Anything we can do to a Box we allow to be done to a Cube and to a ColorCube. So, a Cube is a kind of Box; a ColorCube is a kind of Cube and a kind of Box. When classes follow this "is a kind of" relationship, we generally use a public derivation. In the Package example, we don't want to consider a Package a kind of Box, so we use a private derivation.

  In the header file for the Package class, we declare the Package class to be a private derivation of the Box class in the following line, using the keyword "private".

  class Package : private Box { // private derivation of class Box The rest of the declaration includes two constructors and the public member functions identify(), Store(), empty() and content(). These are the only publicly accessible members of Package. Even though Package inherits all the members of Box, the public members (e.g. grow() and shrink()) are not accessible through a Package object. This has the intended effect.

  Other notable points about the package implementation:

  • The main program and sample run show how the Package class is used.

  • A second main program and sample run show that the compiler generates an error if you try to access the grow() function through a Package object.

  • The Store() function uses the compare() function to determine whether a package fits inside another package. In order to do so, the Store() function needs some mechanism to refer to the host object. (When we call p2.Store(&p1) in the main program, p2 is the host object for this particular call.) This is accomplished using the this pointer. Each member function has a local variable this which points to the host object. Thus the function call r = compare(*this, *item) ; has the intended effect of comparing the host object with the package given in as a parameter.
   

• The following table describes when an inherited member is accessible:

  Accessibility of an Inherited Member

  	In the base class, the inherited member is a:
  Access From	Public Member	Protected Member	Private Member
  Members & friends of a derived class	Yes	Yes	No
  Members & friends of a subsequently derived class	if previous derivations are public or protected	if previous derivations are public or protected	No
  Other functions, using a derived object	if derivation is public	No	No

• Stacks: A stack is a Last-In-First-Out (LIFO) data structure (imagine a stack of papers). When you use a stack, you are allowed to put things on top of a stack or take things off the top of a stack, but you are not allowed to insert or remove things from the middle of a stack. (By the way, the term "stack" here is the same as the term we used when we discussed how local variables are stored. And in this case, using the same term is actually appropriate.) A stack by itself is that interesting. However, stacks are useful as a part of many algorithms (e.g., Depth-First Search).

• We can implement a stack by derivation from the GenQ class from Lecture 17. However, a stack is not a queue. For example, we wouldn't want to allow the client to add a new item at the bottom of the stack. Thus, a private derivation is more appropriate here.

  See GenStack declaration and implementation

• We can specialize GenStack to get a stack of integers that is easier to use. This should be a public derivation of GenStack.

  • IntStack declaration and implementation
    

  • main program and sample run demonstrating use of IntStack.

• We can also specialize GenStack to get a stack of strings.

  • BStringStack declaration and implementation
    

  • main program and sample run demonstrating use of BStringStack.

• Finally, we consider the special situation of pointers to an object of a derived class.

  • We use a base class Person and publicly derive the classes Student and Faculty from Person. Note that Person, Student and Faculty all have a different number of data members. In particular, the amount of storage needed for an object in each class is different. See class declarations for Person, Student and Faculty.

  • In the first program, we have a function foo() which takes a single parameter of type Person& (reference to a person) and a function bar() which takes a Person pointer as its parameter. Note that we are allowed to pass actual parameters of type Student and Faculty to foo() without any explicit type conversion. Similarly, we can pass an address of Student and an address of Faculty to bar() without type conversion. This is because C++ considers a derived class "compatible" with the base class. See sample run.

  • In the second program, we note that this compatibility extends to pointers in general, not just parameters. We can store a Student pointer in a Person pointer, and a Faculty pointer in a Person pointer. However, when we use the Person pointer ptr to invoke the member function id(), the id() function from the Person class is called because the dereferenced pointer *ptr has type Person. See sample run.

  • In the third program, we note that a Person pointer pointer is not compatible with a Student pointer pointer. (See sample run.) Why is that? Suppose we let a Person pointer pointer be compatible with both a Student pointer pointer and a Faculty pointer pointer. Then, we could have: Person **ptrptr1, **ptrptr2 ; Student S("Joe Blow", 19, 2, 3.79) ; Faculty F("Dr. Foo", 45, 17) ; Student *sptr = &S ; Faculty *fptr = &F ; ptrptr1 = &sptr ; ptrptr2 = &fptr ; Now suppose we do the following assignment: *ptrptr1 = *ptrptr2 ; What would happen? The content of fptr would be copied into sptr. Thus, sptr would be pointing to F a Faculty. This would be bad, because the compiler would expect F to have data members year and gpa and F does not have these members.

  • In the fourth program, we have a function SortByAge() which sorts an array of Persons using Selection Sort. See sample run.

  • In the fifth program, we try to use the SortByAge() function to sort an array of Students. After all, Student pointers and Person pointers are compatible. However, this results in a segmentation fault. (See sample run.) The reason for this is that the size of a Person and that of a Student is not the same. In the SortByAge() function, the variable A is treated as an array of Person, even if A is really pointing to a Student. So, the address of A[1] is computed as A + sizeof(Person). This address is incorrect if A is really pointing to an array of Student.

  • The problems with the previous program can be fixed if we modify SortByAge() to sort an array of Person pointers. Then, we can use the same function to sort an array of Student pointers. See program and sample run. The problem we have here is that an array of Student pointers has type Student ** which is not compatible with Person **, as explained above. We could use explicit type casting to force the Student ** pointer into a Person ** pointer, but this is not very good programming practice.

  • Alternatively, we can use an array of Person pointers to point to Students. See program and sample run. Then, we would not have to use explicit type casting, but when we try to print out the array of Students, the year and gpa fields are not printed out because the id() function from the Person class is invoked instead of the id() function from the Student class.

  • Finally, finally, (so final that this wasn't actually discussed in this lecture, but in Lecture 20), in the eighth program we see how to have the best of both worlds. This program uses a new declaration of the Person class, where the id() function is declared as virtual. In this case, when a Person pointer is dereferenced, the compiler generates code that "remembers" the type of the object pointed to and calls the appropriate id() function. Thus, even though each B[i] is a Person pointer, the expression B[i]->id() actually invokes the id() function from the Student class if B[i] was assigned the address of a Student. We can even mix Faculty and Student in the same array and get the correct call to id() in each case. See sample run.