C++ Knowledge series 4

Programming language evolves always along with Compiler's evolvement

The Semantics of Function

•  C++ supports three flavors of member functions: static, nonstatic, and virtual. Each is invoked differently; those differences are the topic of the next section. (A short quiz: Although we cannot say with certainty whether normalize() and magnitude() are virtual or nonvirtual members, we can safely discount the functions as being static, since both (a) directly access the nonstatic coordinate data and (b) are declared to be const members. Static member functions may not do either.)

Varieties of Member Invocation

• A common opinion was that virtual functions were simply a kind of crippled pointer to function and thus redundant…, Therefore, the argument went, virtual functions were simply a form of inefficiency

Non-static Member Functions

•  One C++ design criterion is that a non-static member function at a minimum must be as efficient as its analogous nonmember function.
• This is achieved by internally transforming the member instance into the equivalent nonmember instance.
• In practice, however, the member function is transformed internally to be equivalent to the nonmember instance. Following are the steps in the transformation of a member function:
  • 1. Rewrite the signature to insert an additional argument to the member function that provides access to the invoking class object. This is called the implicit this pointer;
  • 2. if the member function is non-const, insert Class * const this;
  • 3. if the member function is const, insert const Class * const this;
  • 4. Rewrite each direct access of a non-static data member of the class to access the member through the this pointer;
  • 5. Rewrite the member function into an external function, mangling its name so that it's lexically unique within the program.

• The invocation of member function will be internally transformed, with help of copy constructor and the named returned value (NRV) optimization.

 Virtual Member Functions

•   (* ptr->vptr[ 1] ) ( ptr);
• vptr represents the internally generated virtual table pointer inserted within each object whose class declares or inherits one or more virtual functions. (In practice, its name is mangled. There may be multiple vptrs within a complex class derivation.)
• 1 is the index into the virtual table slot associated with normalize().
• ptr in its second occurrence represents the this pointer.
• Objects do not support polymorphism, but the pointer and reference support.
• This is significantly more efficient if magnitude() is declared inline. The explicit invocation of a virtual function using the class scope operator is resolved in the same way as a nonstatic member function:

Static Member Functions

• It can not directly access the non-static members of its class.
• It can not be declared const, volatile, or virtual.
• It does’t need to be invoked through an object of its class, although for convenience, it may.
• A static member function, of course, is also lifted out of the class declaration and given a suitably mangled name.
• Taking the address of a static member function always yields the value of its location in memory, that is, its address. Because the static member function is without a this pointer, the type of its address value is not a pointer to class member function but the type of a nonmember pointer to function.
• That is,&Point3d::object_count();yields a value of type。unsigned int (*)();not of type unsigned int ( Point3d::* )();
• Static member functions, by being this-less and therefore of the same type as an equivalent nonmember function, also provide an unexpected solution to the problem of mixing C++ with the C-based X Window system with regard to the use of callback functions. Take a look at DECLARE_DYNCREATE(class_name) of MFC.

Virtual Member Functions

• We've already seen the general virtual function implementation model: the class-specific virtual table that contains the addresses of the set of active virtual functions for the class and the vptr that addresses that table inserted within each class object. In this section, I walk through a set of possible designs evolving to that model and then step through that model in detail under single, multiple, and virtual inheritance.
• There needs to be some information associated with ptr available at runtime such that the appropriate instance of z() can be identified, found, and invoked. Perhaps the most straightforward but costly solution is to add the required information to ptr. Under this strategy, a pointer ( and, implicitly, a reference as well) holds two pieces of information:
  • 1, The address of the object it refers to;
  • 2. Some encoding of the object’s type or the address of a structure containing that information.
• The problem with this solution is two-fold. First, it adds significant space overhead to the use of pointers regardless of whether the program makes use of polymorphism. Second, it breaks link compatibility with C.
• That is why the keywords virtual is introduced to C++, which indicates that the object shall be added the information in support of polymorphism.
• In C++, polymorphism “exhibits” itself as the potential addressing of a derived class object through a pointer or reference of a public base class.
• How might the table containing the virtual function addresses be constructed? In C++, the set of virtual functions capable of being invoked through an object of its class is known at compile time. Moreover, this set is invariant. It cannot be added to nor can a virtual instance be replaced at runtime. The table, therefore, serves only as a passive repository. Since neither its size nor its contents change during program execution, its construction and access can be completely handled by the compiler. No runtime intervention is necessary.
• Having the address available at runtime, however, is only half the solution. The other half is finding the address. This is accomplished in two steps:
  • 1. To find the table, an internally generated virtual table pointer is inserted within each class object.
  • 2. To find the function’s address, each virtual function is assigned a fixed within the table.
• This is all set up by the compiler. All that is left to do at runtime is invoke the function addressed within the particular virtual table slot.
• The virtual table is generated on a per-class basis. Each table holds the addresses of all the virtual function instances “active” for objects of the table’s associated class.
• Each virtual function is assigned a fixed index in the virtual table. This index remains associated with the particular virtual function throughout the inheritance hierarchy.
• There are three possibilities:
  • 1, It can inherit the instance of the virtual function declared within the base class. Literally, the address of that instance is copied into the associated slot in the derived class’s virtual table;
  • 2. It can override the instance with one of its own. In this case, the address of its instance is placed within the associated slot;
  • 3. It can introduce a new virtual function not present in the base class. In this case, the virtual table is grown by a slot and the address of the function is placed within that slot.
• Within a single inheritance hierarchy, the virtual function mechanism is well behaved; it is both efficient and easily modeled. Support for virtual functions under multiple and virtual inheritance is somewhat less well behaved.

Virtual Functions Under MI

• The complexity of virtual function support under multiple inheritance re-volves around the second and subsequent base classes and the need to adjust the this pointer at runtime.
• The general rule is that the this pointer adjustment of a derived class virtual function invocation through a pointer (or reference) of a second or subsequent base class must be accomplished at runtime. That is, the size of the necessary offset and the code to add it to the this pointer must be tucked away somewhere by the compiler.

From:<<Inside C++ Object Model>>