Realization and reflection of C + + polymorphism Technology

Object-oriented technology first appeared in the 1960 's Simula 67 system, and in the 1970 Paul Ato Laboratory developed Smalltalk system developed. For most programmers, however, C + + is the first available object-oriented programming language. Therefore, many of our concepts and ideas about object-oriented come directly from C + +. However, C + + has chosen a completely different scheme from Smalltalk when it realizes the key polymorphism in object-oriented. The result is that although both surfaces have achieved similar polymorphism, there is a huge difference in practice. Specifically, C + + polymorphism is more efficient, but does not apply to all situations. Many inexperienced C + + developers do not understand this truth, in inappropriate situations forcibly use C + + polymorphism mechanism, fall into the trap of fit and unable to extricate themselves. This article will discuss the limitation and solution of C + + polymorphism technology in detail.

Implementation of two different virtual method calls

The polymorphism of C + + is the base of C + + to realize object-oriented technology. Specifically, when a virtual member function is called by a pointer to a base class, the runtime system will be able to invoke the appropriate member function implementation based on the actual object to which the pointer points. As shown below:

class Base {
　　 public:
　　 virtual void vmf() { ... }
　　 };
　　 class Derived : public Base {
　　 public:
　　 virtual void vmf() { ... }
　　 };
　　 Base* p = new Base();
　　 p->vmf(); // 这里调用Base::vmf
　　 p = new Derived();
　　 p->vmf(); // 这里调用
// Derived::vmf
　　 ...

Notice that the two lines that are highlighted in the code, although their surface syntax is identical, call different function implementations individually. So-called "polymorphism" is for that matter. This knowledge is well known to every C + + developer.

Now that we assume ourselves to be the language's implementation, how do we achieve this polymorphism? With a little thought, it's not difficult to get a basic idea. The implementation of polymorphism requires that we add an indirect layer, intercept the call to the method in this indirect layer, and then invoke the corresponding method implementation based on the actual object to which the pointer points. The indirect layer that we artificially increase in this process is very important, and it needs to do the following:

1. Learn all the information about the method call, including which method was invoked, and what actual parameters were passed in.

2. Learn the actual object that the pointer (reference) points to when the call occurs.

3. According to the information obtained in steps 1th and 2, find the appropriate method to implement the code and execute the call.

The key here is how to find the right way to implement the code in step 3rd. Because polymorphism is in terms of objects, we design with the right method to implement code and object binding together. That is, you must implement a lookup table structure at the object level, based on the object and method information obtained in 1 or 2 steps, find the actual method code address in the lookup table and call it. Now the question becomes, what information should we follow to find the way. There are two different ways to solve this problem, one is to search by name, and the other is to find by location. Rough looks like the two ideas seem to be no big difference, but in practice, the two different ways of achieving this result in a huge difference. We'll examine them in detail below.

In dynamic object-oriented languages such as Smalltalk, Python, and Ruby, the search for the actual method is based on the method name, and the lookup table structure is as follows:

Because this lookup table is a method lookup based on the name of the method, it is inefficient to involve string comparisons in the lookup process. But this kind of look-up table has one outstanding advantage, is the effective space utilization rate is high. To illustrate this point, we assume that there are 100 methods in a base class base that can be overridden by a derived class (so that all the base objects share a method lookup table with 100 entries), and that one of its derived classes derived only intends to overwrite 5 of these methods. Then the derived class object's method lookup table only needs 5 items. When a method call occurs, runtime the string lookup in the method lookup table of this length 5 based on the method name being invoked, if the method is found in the lookup table, executes the call, or the call forwarding (forward) is executed to the base class. This is the standard behavior of the virtual method invocation. When a derived class actually rewrites a small number of methods, the lookup table can be arranged into a linear table, looking in order to compare, in which case the effective space utilization reaches 100%. If a derived class actually overwrites more methods, then a hash table can be used, and if a reasonable hash function is used, it can also be highly efficient in space (typically close to 75%). To achieve a quick lookup of the method. It should be noted that since the compiler can easily obtain the names of all overridden methods, it is possible to perform the standard gperf algorithm to obtain the optimal hash function.