深入探索C++内存模型（4）

C++ 的设计准则之一就是：nonstatic member function 至少必须和一版的nonmember function有相同的效率。

编译器会将member function重写成一个外部函数，对函数名称进行“mangling”处理，使它在程序中成为独一无二的语汇。在这过程中也会施行NRV优化。

一版而言，member的名称前面汇被加上 class 名称，行程独一无二的命名。

对于类中的成员变量也会进行换名，以应对可能在继承关系中引入的同名成员变量。

两个实体如果拥有独一无二的 name mangling，那么任何不正确的调用操作在链接时期就因无法决议（resolved）而失败，有是由我们可以乐观地称此为“确保类型安全的链接行为”（type-safe linkage）。我说“乐观地”是因为它只可以捕捉函数的标记（signature，即函数名称 + 参数数目 + 参数类型）错误，如果“返回类型”声明错误，就没办法检查出来。

当前的编译系统中，有一种所谓的 demangling 工具，用来拦截名称并将其转换回去，使用者仍然可以不关心其内部名称发生的转换。

使用指针调用虚函数会从虚函数表找到对应的虚函数地址，使用该虚函数地址完成函数的调用。

如果使用类域明确地调用虚函数，则会压制由于虚拟机制而产生的不必要的重复查找虚函数表操作。

静态成员函数的特性：

1. 没有 this 指针
   
2. 不能直接存取其 class 中的 nonstatic members
   
3. 不能比声明为 const 、 volatile 或 virtual
   
4. 不需要经由 class object 才被调用 （虽然大部分时候它是这样被调用的）
   

一个 static member function 当然会被体书于 class 声明之外，并给予一个经过“mangled”的适当名称。

如果取一个 static member function 的地址，获得的是其在内存中的位置，也就其地址。由于 static member function 没有 this 指针，所以其地址的类型并不是一个 “指向 class member function 的指针”，而是一个 “nonmember function 的指针”。也就是说：

&Point3d::object_count();

会得到一个数值，类型是：

unsigned int (*)();

而不是：

unsigned int (Point3d::*)();

static member function 由于缺乏 this 指针，因此差不多等同于 nonmember function。它提供了一个意想不到的好处：成为一个 callback 函数，也可以应用在线程（thread）函数上。

在多重继承中支持 virtual functions，其复杂度围绕在第二个及后继的 base class 身上，以及“必须在执行期调整 this 指针”这一点。

对于 derived class 的必要的 this 指针调整操作，必须在执行期完成。即 offset 的大小，以及把 offset 加到 this 指针上头的那一小段程序代码，必须有编译器在某个地方插入。

比较有效率的解决方法是利用所谓的 thunk (thunk 是 knuth 博士的倒拼字）。所谓 thunk 是一小段 assembly 码，用来（1）以适当的 offset 值调整 this 指针，（2）跳到 virtual function 去。

Thunk 技术允许 virtual table slot 继续内含一个简单的指针，因此多重继承不需要任何空间上的额外负担。 slots 中的地址可以直接指向 virtual function，也可以指向一个相关的 thunk（如果需要调整 this 指针的话）。于是，对于那些不需要调整 this 指针的 virtual function，也就不需要承担效率上的额外负担。

调整 this 指针的第二个额外负担就是，由于两种不同的可能：（1）经由 derived class （或第一个 base class）调用，（2）经由第二个（或其后继） base class 调用，同一函数在 virtual table 中可能需要多个对应的 slosts。例如：

Base* pbase1 = new Derived;
Base* pbase2 = new Derived;

delete pbase1;
delete pbase2;

虽然两个 delete 操作导致相同的 derived destructor，但它们需要两个不同的 virtual table slots：

1. pbase1 不需要调整 this 指针（因为 Base1 是最左端 base class，它已经指向 Derived 对象的起始处），其 virtual table slot 需放置真正的 destructor 地址。
   
2. pbase2 需要调整 this 指针，其 virtual table slot 需要相关的 thunk 地址。
   

在多重继承下， 一个 derived class 内含 n-1 个额外的 virtual tables， n 表示其上一层 base class 的数目。因此，单一继承将不会有额外的 virtual table。

在虚拟继承中，也需要调整 this 指针，至于在虚拟继承的情况下要消除 thunks，一般而言已经被证明是一项高难度技术。

当一个 virtual base class 从另一个 virtual base class 派生而来，并且两者都支持 virtual function 和 nonstatic data member 时， 编译器对于 virtual base class 的支持简直就像进了迷宫一行。

作者的建议是，不要在一个 virtual base class 中声明 nonstatic data members。

注意下面的程序片段：

float (Point::*pmf)() = &Point::z;
Point* ptr = new Point3d;

pmf , 一个指向 member function 的指针，被设置为 Point::z() (一个 virtual function) 的地址，ptr 则被指定以一个 Point3d 对象，如果直接由 ptr 调用 z() :

ptr->z();

则被调用的是 Point3d::z()，但如果我们从 pmf 间接调用 z() 呢？

(ptr->*pmf)();

仍然是 Point3d::z() 被调用吗？答案是 yes，也就是说，虚拟机制仍然能够在使用“指向 member function 的指针”的情况下运行。

结合前面章节，对一个 nonstatic member function 取其地址，将获得该函数在内存中的地址，然而对一个 virtual function，其地址在编译时期时候未知的，所能知道的近视 virtual function 在其相关 virtual table 中的索引值。也就是说，对一个 virtual member function 取其地址，所能获得的只是一个索引值。

通过 pmf 来调用 z() 会被内部转化为一个编译时期的式子，一般形式如下：

(*ptr->vptr[(int)pmf])(ptr);

为了让指向 member function 的指针也能够支持多重继承和虚拟继承，Stroustrup设计了下面一个结构体：

struct __mptr {
    int delta;
    int index;
    union {
	ptrtofunc faddr;
	int v_offset;
    };
};

index 和 faddr 分别（不同时）带有 virtual table 索引和 nonvirtual member function 地址。为了方便，当 index 不指向 virtual table 时，会被设置为 -1。

在该模型之下，像这样的调用操作：

(ptr->*pmf)();

会变成：

(pmf.index < 0)
  ? // non-virtual invocation
  (*pmf.faddr)(ptr)
  : // virtual invocation
  (* ptr->vptr[pmf.index] (ptr));

这种方法的缺点是：

1. 每一个调用操作都得付出上述成本，检查其是否为 virtual 或 nonvirtual；
   
2. 当传递一个不变值的指针给 member function 时，它需要产生一个临时性对象。
   

本节测试了函数经由一以方式调用的效率：

1. 指向 nonmember function 的指针；
   
2. 指向 class member function 的指针；
   
3. 指向 virtual member function 的指针；
   
4. 多重继承下的 nonvirtual 及 virtual member function 调用；
   
5. 虚拟继承下的 nonvirtual 及 virtual member function 调用。
   

在 inline 拓展期间，每一个形式参数都会被对应的实际参数取代。其副作用为，不可以只是简单地塞入程序中出现的每一个形式参数，因为这将导致对于时间参数的多次求值操作（evaluation）。

一般而言，面对“会带来副作用的实际参数”，通常都需要引入临时性对象。换句话说，如果实际参数十一个常量表达式（constant expression），我们可以在替换之间先完成其求值操作（evalutaion）；后继的 inline 替换，就可以把常量直接“绑”上去，如果既不是个常量表达式，也不是个带有副作用的表达式，那么就直接代换之。

示例代码如下：

inline int min (int i, int j) {
    return i < j ? i : j;
}
// 调用操作
inline int bar() {
    int minval;
    int val1 = 1024;
    int val2 = 2048;
    /*(1)*/ minval = min(val1, val2);
    /*(2)*/ minval = min(1024, 2048);
    /*(3)*/ minval = min(foo(), bar() + 1);
    return minval;
}

分析如下：
标记为（1）的那一行会被拓展为：

// 参数直接代换
minval = val1 < val2 ? val1 : val2;

标记为（2）的那一行直接拥抱常量：

// 代换之后，直接使用常量
minval = 1024;

标记为（3）的那一行则引发参数的副作用，它需要引入一个临时对象，以避免重复求值（multiple evaluation）：

// 有副作用，所以导入临时对象
int t1;
int t2;
minval = (t1 = foo()), (t2 = bar() + 1), t1 < t2 ? t1 : t2;

如果在 inline 定义中加入一个局部变量，会怎样：

inline int min(int i, int j) {
    int minval = i < j ? i : j;
    return minval;
}

这时，如果我们有一下的调用操作：

int local_var;
int minval;
// ...
minval = min(val1, val2);

会被转化为：

int local_var;
int minval;
int __min_lv_minval;
minval = (__min_lv_minval = val1 < val2 ? val1 : val2),
	  __min_lv_minval;

一般而言，inline 函数中的每一个局部变量都必须被放在函数调用的一个粉笔区段中，拥有一个独一无二的名称。如果 inline 函数以单一表达式（expression）拓展多次，那么每次拓展都需要自己的一组局部变量。如果 inline 函数以分离的多个式子（discrete statements）被拓展多次，那么只需要一组局部变量，就可以重复使用（因为它们被放在一个封闭区段中，有自己的 scope）。

inline 函数中的局部变量，再加上有副作用的参数，可能会导致大量临时对象的产生。特别是如果它以单一表达式（expression）被拓展多次时。

inline 函数对于封装提供了一种必要的支持，可以有效存取封装于 class 中的 nonpublic 数据。它同时也是 C 程序中大量使用的 #define （前置处理宏）的一个安全替代品，特别是如果红肿的参数有副作用的话。然而一个 inline 函数如果被调用太多次的话，会产生大量的拓展码，使程序的大小暴涨。

对于既要安全又要效率的程序，inline函数提供了一个强而有力的工具。然而，与 non-inline 函数比起来，它们需要更加小心地处理。

（全文完）