Inside the C++ Object Model 读书笔记(四)

Chapter 4 The Semantics of Function

4.1 Varieties of Member Invocation

One C++ design criterion is that a nonstatic member function at a minimum must be as efficient as its analogous nonmember function.

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:

// non-const nonstatic member augmentation 
Point3d 
Point3d::magnitude( Point3d *const this ) 
If the member function is const, the signature becomes

// const nonstatic member augmentation 
Point3d 
Point3d::magnitude( const Point3d *const this ) 

2. Rewrite each direct access of a nonstatic data member of the class to access the member through the this pointer:

{ 
   return sqrt( 
     this->_x * this->_x + 
     this->_y * this->_y + 
     this->_z * this->_z ); 
}

3. Rewrite the member function into an external function, mangling its name so that it’s lexically unique within the program:

extern magnitude__7Point3dFv( 
   register Point3d *const this ); 

Name Mangling

In general, member names are made unique by concatenating the name of the member with that of the class. For example, given the declaration

class Bar { public: int ival; ... }; 
ival becomes something like

// a possible member name-mangling 
ival__3Bar 


class Foo : public Bar { public: int ival; ... }; 

// Pseudo C++ Code 
// internal representation of Foo 
class Foo { public: 
   int ival__3Bar; 
   int ival__3Foo; 
   ... 
}; 

Member functions because they can be overloaded, require a more extensive mangling to provide each with a unique name.

Virtual Member Functions

ptr->normalize(); 

//transformed into
( * ptr->vptr[ 1 ])( ptr ); 

The invocation of a virtual function through a class object should always be resolved by your compiler as an ordinary nonstatic member function:

// Point3d obj; 
obj.normalize(); 

for the compiler to transform it internally into

// unnecessary internal transformation! 
( * obj.vptr[ 1 ])( &obj ); 

normalize__7Point3dFv( &obj );

Static Member Functions

&Point3d::object_count(); 
yields a value of type

unsigned int (*)(); 
not of type

unsigned int ( Point3d::* )(); 

4.2 Virtual Member Functions

Each table holds the addresses of all the virtual function instances “active” for objects of the table’s associated class. These active functions consist of the following:

1. An instance defined within the class, thus overriding a possible base class instance

2. An instance inherited from the base class, should the derived class choose not to override it

3. A pure_virtual_called() library instance that serves as both a placeholder for a pure virtual function and a runtime exception should the instance somehow be invoked

Multiple Inheritance

class Base1 { 
public: 
   Base1(); 
   virtual ~Base1(); 
   virtual void speakClearly(); 
   virtual Base1 *clone() const; 
protected: 
   float data_Base1; 
}; 

class Base2 { 
public: 
   Base2(); 
   virtual ~Base2(); 
   virtual void mumble(); 
   virtual Base2 *clone() const; 
protected: 
   float data_Base2; 
}; 

class Derived : public Base1, public Base2 { 
public: 
   Derived(); 
   virtual ~Derived(); 
   virtual Derived *clone() const; 
protected: 
   float data_Derived; 
}; 

transformation to support second base class

Base2 *pbase2 = new Derived; 
//transform to
Derived *temp = new Derived; 
Base2 *pbase2 = temp ? temp + sizeof( Base1 ) : 0; 

The Derived class object contains a vptr for each associated virtual table. (This is shown in Figure 4.2.) The vptrs are initialized within the constructor(s) through code generated by the compiler.

The traditional approach to supporting multiple virtual tables associated with a class is to generate each as an external object with a unique name. For example, the two tables associated with Derived are likely to be named

vtbl__Derived; // the primary table 
vtbl__Base2__Derived; // the secondary table 

With the advent of runtime linkers in support of dynamic shared libraries, the linking of symbolic names can be extremely slow—up to 1 ms per name, for example, on a SparcStation 10. To better accommodate the performance of the runtime linker, the Sun compiler concatenates the multi-ple virtual tables into one. The pointers to the secondary virtual tables are generated by adding an offset to the name of the primary table. Under this strategy, each class has only one named virtual table. "For code used on a number of Sun projects [the speedup] was quite noticeable."

Virtual Functions under Virtual Inheritance

class Point2d { 
public: 
   Point2d( float = 0.0, float = 0.0 ); 
   virtual ~Point2d(); 

   virtual void mumble(); 
   virtual float z(); 
   // ... 
protected: 
   float _x, _y; 
}; 

class Point3d : public virtual Point2d 
public: 
   Point3d( float = 0.0, float = 0.0, float = 0.0 ); 
   ~Point3d(); 

   float z(); 
protected: 
   float _z; 
}; 

the Point2d and Point3d objects are no longer coincident, conversion between the two also requires a this pointer adjustment.

4.3 Function Efficiency

4.4 Pointer-to-Member Functions

the syntax of declaring a pointer-to-member function is

double          // return type 
( Point::*            // class the function is member 
  pmf )         // name of pointer to member 
();             // argument list 

//Thus one writes
double (Point::*coord)() = &Point::x; 

Supporting Pointer-to-Virtual-Member Functions

That is, taking the address of a virtual member function yields its index into its class’s associated virtual table.

( * ptr->vptr[ (int)pmf ])( ptr );  //pmf point to virtual function

Pointer-to-Member Functions under MI

For pointers to members to support both multiple and virtual inheritances, Stroustrup designed the following aggregate structure (see [LIPP88] for the original presentation):

// fully general structure to support 
// pointer to member functions under MI 
struct __mptr { 
   int delta; 
   int index; 
   union { 
      ptrtofunc  faddr; 
      int        v_offset; 
   }; 
}; 

The index and faddr members, respectively, hold either the virtual table index or the nonvirtual member function address. (By convention, index is set to –1 if it does not index into the virtual table.) Under this model, an invocation such as

( ptr->*pmf )() 
//becomes

( pmf.index < 0 ) 
   ? // non-virtual invocation 
   ( *pmf.faddr )( ptr ) 

   : // virtual invocation 
   ( * ptr->vptr[ pmf.index ]( ptr ); 

4.5 Inline Functions

In practice, however, we cannot force the inlining of any particular function,For the request to be honored, the compiler must believe it can “reasonably” expand the function in an arbitrary expression.

In general, there are two phases to the handling of an inline function:

1. The analysis of the function definition to determine the “intrinsic inline-ability” of the function (intrinsic in this context means unique to an implementation).
2. The actual inline expansion of the function at a point of call. This involves argument evaluation and management of temporaries.