Deep Exploration C + + object model-function semantics (the Semantics of Function) __c++

function Semantics (the semantics of function) various invocation methods for member nonstatic member functions

One of the design guidelines for C + +: The nonstatic member function must be at least as efficient as the normal nonmember function.

The "member function entity" is converted to the equivalent "nonmember function entity" internally by the compiler:

1. Rewrite the function signature and insert a This parameter into the member function to indicate the object to which it belongs
//non-const nonstatic membership
Point3D point3d::magnitude ();
-->
Point3D point3d::magnitude (Point3D *const this);//this pointer is const


//------------------------------- --------------
//const nonstatic member
Point3D point3d::magnitude () const;
-->
Point3D point3d::magnitude (const Point3D *const this);

2. Change each access to nonstatic data member through the this pointer to access the

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

3. Rewrite the member function to an external function and mangling the function name to handle the
extern MAGNITUDE__7POINT3DFV (
    register Point3D *const this);

As a result, each invocation is converted as follows:

Obj.magnitude ();
-->
MAGNITUDE__7POINT3DFV (&obj);

Ptr->magnitude ();
-->
MAGNITUDE__7POINT3DFV (PTR);

C + + because you want to support overloading, you need to use mangling to create a unique function name. If you declare extern "C", you will suppress the "mangling" effect of nonmember functions.

(The function signature includes: function name, number of arguments, parameter type), so the return type declares an error and will not be checked out. Virtual member Function

Assuming that normalize () is a virtual function, it is reduced by:

Ptr->normalize ();

will be internally converted to:

(*ptr->vptr[1]) (PTR);

Where vptr is a pointer generated by the compiler, pointing to Virtual table (in fact its name is also "mangled", because in a complex class derivation system, there may be more than one vptrs);

1 is the index value of virtual table slot, which is associated to the normalize () function;

The second PTR represents the this pointer.

The above is to access the virtual function through the pointer (or reference) to the transformation, if it is directly through the object to manipulate, then because the object itself does not have polymorphism, so the call to the virtual function with the ordinary nonstatic member function does not differ:

Point3D obj;
Obj.normalize ();
-->
NORMALIZE__7POINT3DFV (&obj);

(*obj.vptr[1]) (&obj); Semantically correct, but not necessary.

Static member functions

If normalize is a static member function, the following conversions are:

Obj.normalize ();
->
NORMALIZE__7POINT3DSFV ();

Ptr->normalize ();
->
NORMALIZE__7POINT3DSFV ();

Main feature of the Static member functions: It has no this pointer.

The following minor attributes are rooted in its main features: it cannot directly access the nonstatic members in its class; it cannot be declared as const, volatile, or virtual; it does not need to be invoked through class object.

Static member functions is almost equivalent to nonmember function because of the lack of this pointer. It provides an unexpected benefit: to become a callback function. Virtual member Function

To support the virtual function mechanism, you must first be able to have some form of "execution type judgment" for polymorphic objects, such as the following calls that require some relevant information for PTR during the execution period:

Ptr->z ();

To find and invoke the appropriate entity for Z () (for example, Z () of the base class or Z () of a derived class).

To clarify the z () entity, we need to know the true type of the object that PTR refers to, which allows us to select the correct z () entity and the position of the Z () entity so that we can call it.

Here we only discuss virtual functions under a single inheritance system.

Implementation of virtual function: a virtual function table for each class that has a virtual function, which stores the class type information and the address of all virtual function execution periods. Inserts a pointer (vptr) for each class that has a virtual function, which points to the virtual function table for that class. Assigns each virtual function an index in the table.

Using this model to realize the virtual function benefits from in C + +, the address of the virtual function is known at compile time, and this address is fixed unchanged. And the size of the table does not increase or decrease during the execution period.

The virtual function table of a class stores the type information stored at index 0 and all virtual function addresses, which include three kinds: the virtual function defined by this class will overwrite (overriding) A virtual function entity of a possible base class- If the base class is also defined with this virtual function. The virtual function entity that inherits from the base class--The base class is defined, and this class is not defined and inherits directly. A pure virtual function entity. Used to occupy a seat in a virtual function table, sometimes as an execution-time exception handler.

Each virtual function is assigned a fixed index value that remains associated with the entire inheritance system , for example, if Z () has an index value of 2 in the Point virtual function table, the index value in the Point3D virtual function table is also 2.

When a class order inherits the base class of its own virtual functions, the virtual function table is constructed as follows: the virtual functions declared in the base class are inherited--the entity addresses of these virtual functions are copied to the slot in the virtual function table in the inheriting class. If you have a virtual function that rewrites the base class (override), then in 1 you should place the address of the overridden (override) function entity in the corresponding slot instead of copying the base class. If there is a new virtual function defined, the virtual function table is enlarged by a slot to hold the new function entity address.

Let's assume that the Z () function has an index of 4 in the Point virtual function table, back to the original question--how to ensure that the correct z () entity is invoked during the execution period. The tricky part is that the compilation will make a small transition:

Ptr->z ();
Transformed by the compiler into:
(*ptr->vptr[4]) (PTR);

This transformation guarantees that the call to the correct entity, because:

Although we do not know the true type of PTR , it can find the correct type of virtual function through vptr--the address of Z () is always placed in slot 4 throughout the inheritance system. about Rtti and type information

I'm talking about the type information stored in the virtual table where the index is 0, which is mainly used to support Rtti:

The execution type recognition (Runtime type identification RTTI) RTTI only supports polymorphic classes, that is, a class that does not define a virtual function cannot be RTTI. Failure to dynamic_cast the pointer returns NULL, and recognition throws Bad_cast exception for reference. typeID can return a const type_info& to obtain type information.

1 is because the implementation of RTTI is to obtain the type_info* stored in the virtual function table by vptr, and it does not make much sense to provide rtti for the non polymorphic class.
2 is because the pointer can be assigned a value of 0 to represent no object, but the reference is not.
3 is because although the 1th point is that Rtti only supports polymorphic classes, typeid and type_info can also be used for both built-in types and all non polymorphic classes. The difference with polymorphic classes is that the Type_info object of a non polymorphic class is obtained statically (so it cannot be called "execution type recognition"), whereas polymorphic classes are obtained during the execution period.