These observations lead us to decide that the display function will take three arguments: the stream on which to generate the output, the number of the row to write, and a bool that will indicate whether to pad the picture to its full width With these decisions, we can fill in the details of the Pic_base family of classes:

class Pic_base { // no public interface typedef std::vector<std::string>::size_type ht_sz; typedef std::string::size_type wd_sz; virtual wd_sz width() const = 0; virtual ht_sz height() const = 0; virtual void display(std::ostream&, ht_sz, bool) const = 0; };

We start by defining shorthand names for the size_types that we'll need in our implementation Thinking ahead, we can see that the underlying data will still be a vector<string>, so the size_type member of vector<string> will be the right type to represent the height of a picture, and the one from string will be the one we need for the width We'll abbreviate these types as ht_sz and wd_sz respectively The other task is to define our virtual functions for the base class, which you'll notice take a new form: In each case we say = 0 where the body would appear This syntax indicates our intention that there be no other definition of this virtual function Why did we define these functions this way To answer this question, let's begin by thinking about what the definitions would look like if we tried to write them In our design, Pic_base exists only to act as the common base class for our concrete picture classes We will create objects of these concrete types as a result of executing one of the Picture operations, or in response to a user's creating a Picture from a vector<string> None of these operations directly creates or manipulates Pic_base objects If there are never any Pic_base objects, then what would it mean to take the height or width of a Pic_base object (as opposed to doing so for an object of a type derived from Pic_base) These operations are needed only for the derived classes, in which there always will be a concrete picture For a Pic_base itself, there is nothing of which to take the height or width Instead of forcing us to concoct an arbitrary definition for these operations, the C++ language lets us say that there will be no definition for a given virtual function As a side effect of declining to implement the virtual function, we also promise that there will never be objects of the associated type There may still be objects of types derived from this type, but there are no objects of its exact type The way that we specify that we don't intend to implement a virtual function is to say = 0, as we did on height, width, and display Doing so makes it a pure virtual function By giving a class even a single pure virtual function, we are also implicitly specifying that there will never be objects of that class Such classes are called abstract base classes, because they exist only to capture an abstract interface for an inheritance hierarchy They are purely abstract: There are no objects of the base class itself Once we give a class any pure virtuals, the compiler will enforce our design by preventing us from creating any objects of an abstract class

As with virtual itself, the fact that a function is a pure virtual is inherited If a derived class defines all of its inherited pure virtual functions, it becomes a concrete class, and we can create objects of that class However, if the derived class fails to define even a single pure virtual function that it inherits, then the abstract nature is also inherited In this case the derived class is itself abstract, and we will not be able to create objects of the derived class Because each of our derived classes is intended to model a concrete class, we know that we have to redefine all of the virtuals in each of the derived classes The only other things we have to think about right now are what data each of our derived classes will contain, and the associated question of how we will construct objects of each type We designed these classes to model the structure