Virtual constructors

C# Essentials
eBook

$9.99

eBookFrenzy.com

One of the primary goals of using a factory is to organize your code so you don t need to select the exact constructor type when creating an object. That is, you can tell a factory: I don t know precisely what kind of object I need, but here s the information. Create the appropriate type.

In addition, during a constructor call the virtual mechanism does not operate (early binding occurs). Sometimes this is awkward. For example, in the Shape program it seems logical that inside the constructor for a Shape object, you would want to set everything up and then draw( ) the Shape. The draw( ) function should be a virtual function, a message to the Shape that it should draw itself appropriately, depending on whether it is a Circle, a Square, a Line, and so on. However, this doesn t work inside the constructor because virtual functions resolve to the local function bodies when called in constructors.

If you want to be able to call a virtual function inside the constructor and have it do the right thing, you must use a technique to simulate a virtual constructor. This is a conundrum. Remember, the idea of a virtual function is that you send a message to an object and let the object figure out the right thing to do. But a constructor builds an object. So a virtual constructor would be like saying, I don t know exactly what kind of object you are, but build the right type anyway. In an ordinary constructor, the compiler must know which VTABLE address to bind to the VPTR, and even if it existed, a virtual constructor couldn t do this because it doesn t know all the type information at compile time. It makes sense that a constructor can t be virtual because it is the one function that absolutely must know everything about the type of the object.

And yet there are times when you want something approximating the behavior of a virtual constructor.

In the Shape example, it would be nice to hand the Shape constructor some specific information in the argument list and let the constructor create a specific type of Shape (a Circle or a Square) with no further intervention. Ordinarily, you d have to make an explicit call to the Circle or Square constructor yourself.

Coplien[143] calls his solution to this problem envelope and letter classes. The envelope class is the base class, a shell that contains a pointer to an object, also of the base class type. The constructor for the envelope determines (at runtime, when the constructor is called, not at compile time, when the type checking is normally done) what specific type to make, creates an object of that specific type (on the heap), and then assigns the object to its pointer. All the function calls are then handled by the base class through its pointer. It s really just a slight variation of the State pattern, where the base class is acting as a surrogate for the derived class, and the derived class provides the variation in behavior:

The base class Shape contains a pointer to an object of type Shape as its only data member. (When you create a virtual constructor scheme, exercise special care to ensure this pointer is always initialized to a live object.) This base class is effectively a proxy because it is the only thing the client code sees and interacts with.

Each time you derive a new subtype from Shape, you must go back and add the creation for that type in one place, inside the virtual constructor in the Shape base class. This is not too onerous a task, but the disadvantage is you now have a dependency between the Shape class and all classes derived from it.

In this example, the information you must hand the virtual constructor about what type to create is explicit: it s a string that names the type. However, your scheme can use other information for example, in a parser the output of the scanner can be handed to the virtual constructor, which then uses that information to determine which token to create.

The virtual constructor Shape(type) cannot be defined until after all the derived classes have been declared. However, the default constructor can be defined inside class Shape, but it should be made protected so temporary Shape objects cannot be created. This default constructor is only called by the constructors of derived-class objects. You are forced to explicitly create a default constructor because the compiler will create one for you automatically only if there are no constructors defined. Because you must define Shape(type), you must also define Shape( ).

The default constructor in this scheme has at least one important chore it must set the value of the s pointer to zero. This may sound strange at first, but remember that the default constructor will be called as part of the construction of the actual object in Coplien s terms, the letter, not the envelope. However, the letter is derived from the envelope, so it also inherits the data member s. In the envelope, s is important because it points to the actual object, but in the letter, s is simply excess baggage. Even excess baggage should be initialized, however, and if s is not set to zero by the default constructor called for the letter, bad things happen (as you ll see later).

The virtual constructor takes as its argument information that completely determines the type of the object. Notice, though, that this type information isn t read and acted upon until runtime, whereas normally the compiler must know the exact type at compile time (one other reason this system effectively imitates virtual constructors).

The virtual constructor uses its argument to select the actual ( letter ) object to construct, which is then assigned to the pointer inside the envelope. At that point, the construction of the letter has been completed, so any virtual calls will be properly redirected.

As an example, consider the call to draw( ) inside the virtual constructor. If you trace this call (either by hand or with a debugger), you can see that it starts in the draw( ) function in the base class, Shape. This function calls draw( ) for the envelope s pointer to its letter. All types derived from Shape share the same interface, so this virtual call is properly executed, even though it seems to be in the constructor. (Actually, the constructor for the letter has already completed.) As long as all virtual calls in the base class simply make calls to identical virtual functions through the pointer to the letter, the system operates properly.

To understand how it works, consider the code in main( ). To fill the vector shapes, virtual constructor calls are made to Shape. Ordinarily in a situation like this, you would call the constructor for the actual type, and the VPTR for that type would be installed in the object. Here, however, the VPTR used in each case is the one for Shape, not the one for the specific Circle, Square, or Triangle.

In the for loop where the draw( ) and erase( ) functions are called for each Shape, the virtual function call resolves, through the VPTR, to the corresponding type. However, this is Shape in each case. In fact, you might wonder why draw( ) and erase( ) were made virtual. The reason shows up in the next step: the base-class version of draw( ) makes a call, through the letter pointer s, to the virtual function draw( ) for the letter. This time the call resolves to the actual type of the object, not just the base class Shape. Thus, the runtime cost of using virtual constructors is one extra virtual indirection every time you make a virtual function call.

To create any function that is overridden, such as draw( ), erase( ), or test( ), you must forward all calls to the s pointer in the base class implementation, as shown earlier. This is because, when the call is made, the call to the envelope s member function will resolve as being to Shape, and not to a derived type of Shape. Only when you forward the call to s will the virtual behavior take place. In main( ), you can see that everything works correctly, even when calls are made inside constructors and destructors.

Destructor operation

The activities of destruction in this scheme are also tricky. To understand, let s verbally walk through what happens when you call delete for a pointer to a Shape object specifically, a Square created on the heap. (This is more complicated than an object created on the stack.) This will be a delete through the polymorphic interface, and will happen via the call to purge( ).

The type of any pointer in shapes is of the base class Shape, so the compiler makes the call through Shape. Normally, you might say that it s a virtual call, so Square s destructor will be called. But with the virtual constructor scheme, the compiler is creating actual Shape objects, even though the constructor initializes the letter pointer to a specific type of Shape. The virtual mechanism is used, but the VPTR inside the Shape object is Shape s VPTR, not Square s. This resolves to Shape s destructor, which calls delete for the letter pointer s, which actually points to a Square object. This is again a virtual call, but this time it resolves to Square s destructor.

C++ guarantees, via the compiler, that all destructors in the hierarchy are called. Square s destructor is called first, followed by any intermediate destructors, in order, until finally the base-class destructor is called. This base-class destructor contains code that says delete s. When this destructor was called originally, it was for the envelope s, but now it s for the letter s, which is there because the letter was inherited from the envelope, and not because it contains anything. So this call to delete should do nothing.

The solution to the problem is to make the letter s pointer zero. Then when the letter base-class destructor is called, you get delete 0, which by definition does nothing. Because the default constructor is protected, it will be called only during the construction of a letter, so that s the only situation where s is set to zero.

Although it s interesting, you can see this is a complex approach, and the most common tool for hiding construction will generally be ordinary Factory Methods rather than something like this virtual constructor scheme.