题目1.1 - 分布及期望值

第一问求参数c的值。根据概率论的定义，应该要有，进一步求解：

可以求得，即密度分布函数:

第二问求的均值，根据定义，。

在笔者整理的数学方法技巧整理中提及了如何对复合函数进行积分：

于是有。

这题最后求的方差，根据定义，，对于连续型分布来说，。

上一题已经得出了，现在是求即可。

故。

题目1.2 - 边缘分布

已知, 求边缘密度函数。

随机变量X边缘密度函数：

同理可得Y的边缘密度函数：

第二问两个变量的相关性。

其中：

首先通过定义以及X与Y各自的边缘分布函数求得，。

而：

求得。同时根据题1.1的方差定义式，各自求得 。

故。

题目1.3 - 泰勒展开

第三题是求在的三级泰勒展开。

首先：

故得到：

题目1.4 - 矩阵的行列式及迹

令矩阵。

求三阶矩阵的行列式有公式，加上运算量大，笔者直接用R计算了得到:

迹就简单了，根据定义式 甚至手算一下：

因为太简单了，R甚至不提供这个函数，可以使用：

1

sum(diag(A))

题目1.5 - 驻点

有如下两个二元函数：

其中c是实数常数，证明是两个函数的驻点。

首先求函数的一阶导数:

令：

都解得，即为两个函数的一个驻点。

接下来是通过Hessian矩阵判断是这两个函数的极值点。

首先求得两个函数的二阶导：

显然是正定矩阵，故是f(x,y)的极小值点。

而顺序主子式，，为不定矩阵，无法判断极值情况。

题目1.6 - 贝叶斯法则

首先先要知道公式。

简要介绍问题：假设有的人口患某种病，表示此人患某病，而表示此人健康，某检测方法测试结果表示阳性，表示阴性。病患被检测出阳性的概率是，健康阴性结果的概率是。

第一问求。

第二问求。

首先提取第一句以及后面两句话的信息：

进而推出：

根据贝叶斯定理有：

同理第二问：

之前完成了Effective C++系列之后，整个人就懒起来了，加之春节假期，几乎整个2月份就没有整理写博客了。

回到之前，因为C++后台开发基本上都要求熟悉Linux以及Socket，所以学习TCP以及Socket编程是不能避免的事情。

本篇博客首先介绍基本的接口，随后给出一个简单的单线程，面向单个用户的演示程序。

用到的接口

1
2
3
4
5
6
7
8
9
10
11

// 创建一个Socket并返回对应的文件描述符。
int socket(int domain, int type, int protocol);

// 将指定的sockfd与指定地址addr绑定起来。
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

// 使指定sockfd可以被监听，即支持后续的accept()函数。
int listen(int sockfd, int backlog);

// 通过sockfd接受外部的连接，成功接受后，addr会存有外部连接的地址信息。
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

注意socket并不一定是TCP的，也可以是unix等通信协议，无非是TCP用得比较多而已。

在编写的过程中，通过man得知使用上述函数所需要的头文件，并且其中带有样例，可以参考怎么初始化一些数据结构。

相信接触过机器学习的人，应该对如下的公式很熟悉:

回归问题中这个公式用来作预测函数，分类问题中则作为线性判别的函数。而求得参数w成为了关键。

该部分主题是杂项讨论，已经是书的尾声了。先介绍剩下的三个条款，然后再发表笔者这段时间的感想吧。

条款53:不要轻忽编译器的警告

笔者认为如果不是没办法解决，no warnings应该是需要满足的，这个条款也不需要过多的介绍，直接给出书上的建议吧:

• 严肃对待编译器发出的警告信息。努力在你的编译器的最高警告级别下争取no warnings。
• 不要过度依赖编译器的报警能力，因为不同编译器对待事情的态度并不相同。一旦移植到另一个编译器上，原本依赖的警告信息有可能消失。

条款54:让自己熟悉包括TR1在内的标准程序库

既然作为C++的使用者，当开始开发实际的项目的时候，肯定会用到语言提供的库，因为重复造轮子对于项目开发来说是一件成本极高的事情。而了解STL的接口，可以节省大部分的开发时间。

TR1自身只是一份文档，而条款55提及的Boost库实现了文档中的大多数。

条款55:让自己熟悉Boost

笔者认为，Boost里面很多特性已经成为了C++11标准了，其中的智能指针，function对象等。C++因为历史原因，语言特性的更新速度较其他流行语言慢，虽然现在C++1x不断地提出新的特性标准。但到目前为止(2018年)，C++11才成为主流，虽然C++14已经发布了不少时间，C++17接近发布的尾声了。然而现在大部分的厂商才较好地实现了C++11的特性，所以一些实用的功能而标准库，C++程序员可以尝试去Boost里面找找。

书上也讲了不少，但是笔者认为，最后这两个条款，告诉读者去哪里能了解就可以了。至此，Effective C++一书完结。

后记

在写Effective C++这个系列的博客的时候，中间有那么一丝一丝的感想，到了结束写后记的时候却感觉没什么可以写的。

笔者应该算是脱离了初学者时期的人了，在根据自己理解写下博客的时候，前半本的条款应该多多少少有实践经验，写起来比较快。到了2/3这样地方的时候，明显实践不够了，需要照着原书内容看几遍才能想通道理。这个时候脑子里轻轻飘过放弃这个系列后面部分的念头，不过最后还是坚持下来了。

终于完成了这个系列。同时也意识到自己实践还不够，革命尚未成功。

感想就先写这么多吧。

从此开始进入定制new和delete主题，因为C++手动管理内存的双面性，因此了解new和delete是十分必要的。时至今日，垃圾回收(Garbage Collection，GC)十分流行，主流的的语言里面也只有C和C++没有GC的支持，下图是2018的TIOBE语言使用统计:

可以看到Top 10的语言里面除C和C++以外都是具有GC的语言。GC固然会带来程序性能的下降，但是免去手动管理内存带来的开发效率的提高更加明显，Top 1的Java就很好地说明了这点。而且在多线程的挑战下，手动内存管理变得尤其困难，笔者曾尝试过写一个多线程Socket程序，却总是崩溃，找了三天才找出是自己没有正确管理好内存。当一个执行线程开始使用一个对象的时候，该对象已经在其他线程中被析构了。因此从这点看来，C++需要耗费不少精力才能学好。

Effective C++里面只有operator new的出现，如果读者已经阅读过《深度探索C++对象模型》的话，应该也接触过new operator，要注意这两者的区别。

条款49:了解new-handler的行为

当operator new因无法满足所要求的内存需求而抛出异常前，其中一步会调用客户制定的错误处理函数，即所谓的new-handler:

1
2
3
4
5

namespace std
{
	typedef void (*new_handler)();
	new_handler set_new_handler(new_handler p) throw();
}

也就是说一旦调用了set_new_handler之后，在申请内存失败的时候则会调用输入p函数。而一个设计良好的new-handler则应该有以下的行为:

• 让更多的内存可被使用。类似GC过程，或者在程序初始化时开辟更大块的内存。
• 安装另外一个new-handler。让有能力处理的new-handler接手。
• 卸除new-handler。直接让operator new失败时抛出异常。
• 抛出bad_alloc异常。
• 不返回，调用abort()或者exit()。

一般没有太大的必要去定制new-handler，如果非要定制的话，引用书上的实现:

1
2
3
4
5
6
7
8

class Widget
{
public:
	static std::new_handler set_new_handler(std::new_handler p) throw();
	static void* operator new(std::size_t size) throw(std::bad_alloc);
private:
	static std::new_handler currentHandler;
};

除非是const的静态成员，否则需要把定义式写在类的定义外:

1

std::new_handler Widget::currentHandler = 0;	// 初始化为null

标准版的set_new_handler:

1
2
3
4
5
6
7
8

std::new_handler Widget::set_new_handler(std::new_handler p) throw()
{
	std::new_handler oldHandler = currentHandler;

	currentHandler = p;

	return oldHandler;
}

Widget::operator new行为如下:

1. 调用标准set_new_handler，告知Widget的错误处理函数。会将Widget::currentHandler = ${global new-handler}。
2. 调用global operator new，执行实际的内存分配。如果分配失败则调用Widget::currentHandler。
3. global operator new成功分配，返回内存指针。Widget::~Widget()会管理global new-handler，会恢复Widget::operator new调用前global new-handler。

后面原作也用了详细的代码介绍了上面的三个过程，这里省略掉一是因为这部分可以查原书代码了解，二是笔者对这部分了解不深，基本上仍然处于初次接触的水平，三是该条款重点是了解set_new_handler以及相关的过程即可。

条款50:了解new和delete的合理替换时机

对于绝大多数的C++程序员，语言提供的原始的operator new和operator delete基本上可以满足程序的需求，很少人想到去重载(原书上用的“替换”)这两个operator。书上列出了三个最常见的理由:

• 用来检测运用上的错误。
• 为了强化效能。例如插入一些内存碎片整理的算法。
• 为了收集使用上的统计数据。

总的来说，就是改变原有的行为，修改分配规则，或者插入一些信息记录的步骤。书上也给出定制operator new的一般方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// 让分配的对象具有签名
static const int signatrue = 0xDEADBEEF;	// 特征值
typedef unsigned char Byte;

// 暂时忽略一些小错误
void* operator new(std::size_t size) throw(std::bad_alloc)
{
	using namespace std;

	size_t realSize = size + 2 * sizeof(int);	// 空出2个int存放signature

	void* pMem = malloc(realSize);				// 调用malloc分配内存

	if(!pMen) throw bad_alloc();

	*(static_cast<int*>(pMen)) = signatrue;		// 在对象头存放signature

	// 找到分配块的最后两个字节，并写入signatrue
	*(reinterpret_cast<int*>(static_cast<Byte*>(pMem) + realSize - sizeof(int))) = signatrue;

	// 返回原本申请大小对象实际指针位置，在开头signature后的第一个字节
	return static_cast<Byte*>(pMem) + sizeof(int);
}

例子中的主要缺陷是没有遵循operator new的原则，如应该有一个循环调用new-handling的行为，直到所有尝试都失败，具体可以看条款51。

对齐(alignment)的问题，因为C++底层的代码必然接触到操作系统、甚至硬件相关的这样的细节，重载operator new可以做到对齐的修正，提高运行速度。

一般需要修改默认的operator new和operator delete的理由如下:

• 为了检测运用错误。
• 为了收集动态分配内存的使用统计信息。
• 为了增加分配和归还的速度。
• 为了降低缺省内存管理器带来的额外空间开销。
• 为了弥补缺省分配器的非最佳对齐(suboptimal alignment)。例如指针值在32位系统是4倍数等。
• 为了将相关对象成簇集中。减少缺页异常(Page Faults)。
• 为了获得非传统的行为。

条款51:编写new和delete时固守常规

先给出结论:

• operator new应该内含一个无穷循环，并在其中尝试分配内存，如果它无法满足内存需求，就该调用new-handler。它也应该有能力处理0 bytes申请。Class专属版本则应该处理“比正确大小更大的(错误)申请”。
• operator delete应该在收到null指针时不做任何事。Class专属版本则还应该处理“比正确大小更大的(错误)申请”。

C++规定，即便要求客户要求0 bytes，operator new也会返回一个合法指针。一份常规的non-member operator new伪码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

void* operator new(std::size_t size) throw(std::bad_alloc)	// 定制的函数可以接受额外的参数
{
	using namespace std;

	if(size == 0)			// 0-byte提为1-byte请求
	{
		size = 1;
	}

	while(true)				// 直到申请成功为止，或者程序崩溃
	{
		尝试分配 size bytes;

		if(成功分配)
		{
			return 成功分配的指针值;
		}

		// 分配失败
		new_handler globalHandler = set_new_handler(0);

		set_new_handler(globalHandler);

		if(globalHandler)
		{
			(*globalHandler)();
		}
		else
		{
			throw std::bad_alloc();
		}
	}
}

如果是Class专属版的operator new:

1
2
3
4
5
6
7
8
9
10
11

class Base
{
public:
	static void* operator new(std::size_t size) throw(std::bad_alloc);
	...
};

class Derived : public Base 	// Derived并没有声明自己的operator new
{...};

Derived* pd = new Derived;

那么问题就很明显了，Derived的大小大于等于Base，这样重载的operator new执行出来的Derived的尺寸是正确的吗？

虽然很怪异，但是如果Base::operator new这样实现:

1
2
3
4
5
6
7
8

void* Base::operator new(std::size_t size) throw(std::bad_alloc)
{
	if(size != sizeof(Base))		// 尺寸匹配不上
	{
		return ::operator new(size);	// 交给标准的operator new处理
	}
	...					// 正常流程
}

把责任甩开可以解决问题。

如果重载operator new[]的话，考虑到Base的子子孙孙，bytes % sizeof(Base)的值就不一定为零了，所以重载的时候要考虑的问题还真不少。

接下来就是operator delete的问题，首先记住“删除null指针永远安全”，如下一份non-member operator delete的伪码:

1
2
3
4
5
6

void operator delete(void* rawMemory) throw()
{
	if(rawMemory == 0) return;		// 不处理空指针

	...				// 剩余的delete动作
}

同样，考虑到Base的子子孙孙，Base专属版的operator delete`应该这么实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

class Base
{
public:
	static void* operator new(std::size_t size) throw(std::bad_alloc);
	static void operator delete(void* rawMemory, std::size_t size) throw();
	...
};

void Base::operator delete(void* rawMemory, std::size_t size) throw()
{
	if(rawMemory == 0) return;

	if(size != sizeof(Base))		// 甩锅给标准版operator delete
	{
		::operator delete(rawMemory);
		return;
	}

	...		// 剩余的归还动作。
}

注意，如果没有virtual关键字修饰的析构函数，operator delete也不会接收到正确的size。所以在一个继承里面，virtual关键字是必须要考虑的。

条款52:写了placement new也要写placement delete

placement new和placement delete应该是更少见的语法了。什么是placement new:

1

如果operator new接受的参数除了一定会有的那个size_t之外还有其他，这边是所谓的placement new。

有很多版本的placement new，其中最为有用的一个是“接受一个指针指向对象该被构造之处”:

1

void* operator new(std::size_t, void* pMemory) throw();

同样，如果接受额外参数的operator delete也成为placement delete。原书上给出了加了日志功能的placement new/delete的例子:

1
2
3
4
5
6
7
8
9
10
11
12

class Widget
{
public:
	...
	static void* operator new(std::size_t, std::ostream& logStream) throw(std::bad_alloc);

	static void operator delete(void* pMemory) throw();

	static void operator delete(void* pMemory, std::ostream& logStream) throw();

	...
};

placement new一定要有对应版本的placement delete，若placement new过程抛出了异常，需要恢复而调用operator delete时，是寻找参数匹配的placement delete，假如没有提供的话，那么就不会执行恢复步骤产生内存泄漏。例如上述代码的成对的placement new/delete。当:

1

Widget* pw = new(std::cerr) Widget;

发生异常，除了原有的log输出到std::cerr中，因为具有参数匹配的placement delete被调用，因而不会有泄漏的问题。

还有，写了placement new就会产生名字掩盖问题:

1
2
3
4
5
6
7
8
9
10
11

class Base
{
public:
	...
	static void* operator new(std::size_t size, std::ostream& logStream) throw(std::bad_alloc);
	// 这里只有placement new而没有operator new，global operator new被掩盖了
};

Base* pb = new Base;		// 调用失败，正常的operator new被掩盖了

Base* pb = new (std::cerr) Base;		// OK

同理:

1
2
3
4
5
6
7
8
9
10
11
12

class Derived : public Base
{
public:
	...
	static void* operator new(std::size_t size) throw(std::bad_alloc);

	...
};

Derived* pd = new (std::clog) Derived;		// 错误，Base中的placement new被掩盖了

Derived* pd = new Derived;					// OK

所以在写自己的placement new/delete时，要考虑该类需不需要一般形式的operator new。

即是，声明placement new/delete时，不要忘记了这样会掩盖正常版本的operator new/delete。

从此开始进入模板与泛型编程，这也是一般C++程序员较少接触的部分。如果读者有使用C++里的标准模板库(Standard Template Librarry,STL)的话，能够多多少少地体会到模板的威力。

正如书上所说，这里的内容不能让读者成为专家级的template程序员，但可以让读者成为一个比较好的template程序员。笔者认为这里的意思是介绍一些模板编程的基本知识，例如更好地使用STL，或者进行一些简单的模板编程。因为一些更加进阶的玩法，例如在编译器利用模板编程完成某些运算等这些内容，要对模板元编程(Template Metaprogramming)十分熟悉，这要求编程人员对C++的语法特性十分了解，甚至要对准备编译源文件的编译器十分了解。

笔者自上个主题后期开始的条款就呈现出经验不足，对条款的解释能力开始下降，总结一下无非自己的编程经历也只能理解到书的前半部分，后面部分笔者仍然任重而道远。笔者在剩下的部分里尽自己最大的能力，不足的地方请多指教。

条款41:了解隐式接口和编译期多态

有关C++模板编程的原理，读者们可以读《C++ Template》这本书了解。在开始介绍条款之前，读者们首先要了解模板是怎么编译的，例如:

1
2
3
4
5
6
7
8

// 假定有个列表类
template<typename T>
class List
{
public:
	T operator[](int idx) const;	// 假设该List类模板重载下标访问元素函数
...
};

在编程中，这个类模板被使用了:

1

List<int> intList;

在编译期，template是不会被编译的，而是先产生一个模板类:

1
2
3
4
5
6
7

// 一般会有mangling发生，例如这个模板类会名为IList之类的，但是这里不考虑mangling的问题
class List
{
public:
	int operator[](int idx) const;	// int版的List，该函数的返回类型T被替换为了int
	...
};

然后编译器才会去编译这个类模板的实例。介绍这个原理的意义在于要说明，在类模板有实例之前，类模板里面有什么内容，编译器是不会理会的，例如:

1
2
3
4
5
6
7
8
9

template<typename T>
class Container
{
public:
	void fun(const T& obj)
	{
		obj.call();			// T类具有call函数
	}
};

如果来了一个Container<float>，可想而知，当然是报错的。编译器也不会对类模板以及模板类有太多的检查，只要产生出来的模板类有符合模板类里面有的行为即可。笔者仿照书上的例子来说明结合隐式类型转换，模板编程会变得多困难:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

class A
{
public:
	operator int()()		// 假定类A有个向int转换的重载
	{
		return 33;
	}
};

class B
{
public:
	A& size()			// 一般的size认为是返回对象的大小，但是B不按套路来，返回a
	{
		return a;
	}
private:
	A a;
};

template<typename T>
void fun(T& obj)
{
	if(obj.size() > 10)			// 这个函数模板要求T类型有size()函数
	{
		cout << "Greater than 10." << endl;
	}
	else
	{
		cout << "Less than 10" << endl;
	}
}

int main(int argc, char* argv)
{
	B b;

	fun(b);

	return 0;
}

看到输出:

1

Greater than 10.

也就是说，fun里面，B的实例是符合有size函数这个约束的，而B::size()返回的A类型不能与int直接比较，而是调用了A::operator int()作了隐式转换之后比较。

这个例子要说明的是，模板推断的双面性，一方面类型推断的能力为编程人员带来了遍历，可以少写一些类型转换等语句，也就是语法糖吧;坏处就是推断太强大了，以至于做了隐式转换可能产生非预期的结果。

而这个推断是基于有效表达式的。这也是书上要介绍的编译期多态，也就是在编译器决议出用什么版本的函数。

条款42:了解typename的双重意义

在声明模板的时候:

1
2
3

template<typename T>
class Container
{...};

与:

1
2
3

template<class T>
class Container
{...};

里的typename和class是等价的关键字，但是在用到某个类模板里的内置类型时，例如:

1

std::vector<Object>::iterator iter;		// 用到了vector里面的迭代器

然而有可能在编译过程中，编译器可能认为std::vector<Object>::iterator是vector里面的一个成员变量，而真实情况是vector里面的一个嵌套从属类型，编译器有可能会报错。这时改成:

1

typename std::vector<Object>::iterator iter;

问题解决，这时候的typename是不能用class关键字代替的，这里的typename声明std::vector<Object>::iterator是一个类型，而不是某种实例变量。

条款43:学习处理模板化基类内的名称

该条款涉及到:

• 模板的特化

笔者反复看这个条款，最后也完全理解这个条款想讲的是什么。但是推断应该是与类设计相关的问题。引用书上的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

class CompanyA
{
public:
	// 每个公司都有向该公司发送文本的函数
	void sendCleartext(const std::string& msg);
	void sendEncryted(const std::string& msg);
	...
};

class CompanyB
{
public:
	// 公司B也有
	void sendCleartext(const std::string& msg);
	void sendEncryted(const std::string& msg);
	...
};

...

class MsgInfo {...};		// 承载信息实体的类

template<typename Company>
class MsgSender				// 发送消息给公司的类模板
{
public:
	...
	void sendClear(const MsgInfo& info)
	{
		std::string msg;
		// 根据info产生信息
		Company c;
		c.sendCleartext(msg);	// 模板中调用sendCleartext()函数发送消息
	}

	void sendSecret(const MsgInfo& info)
	{
		std::string msg;
		// 根据info产生信息
		Company c;
		c.sendEncryted(msg);	// 模板中调用sendEncryted()函数发送加密消息
	}
};

接着为了让发送消息有日志，编写一个可以记日志的LoggingMsgSender:

1
2
3
4
5
6
7
8
9
10
11
12
13

template<typename Company>
class LoggingMsgSender : public MsgSender<Company>
{
public:
	...
	void sendClearMsg(const MsgInfo& info)
	{
		...	//	发送前记日志
		sendClear(info);		// 调用MsgSender::sendClear()，但是无法通过编译
		... //	发送后记日志
	}
	...
};

问题的根源在于，当编译器处理class template LoggingMsgSender定义式时，首先要知道MsgSender的定义式，但是MsgSender是一个模板，也就是说需要一个MsgSender<Company>的实例的定义式。而MsgSender有可能有特化的版本，特化的版本与一般的模板又不一样，如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class CompanyZ			// Z公司类
{
public:
	...
	// 这个类不提供sendCleartext函数
	void sendEncryted(const std::string& msg);	// 仅提供发送加密消息的函数
	...
};

template<>				// 为了CompanyZ与众不同的行为提供一个全特化版本的类模板
class MsgSender<CompanyZ>
{
public:
	...
	void sendSecret(const MsgInfo& info)	// 因此这个特化的类模板也只提供发送密文的函数
	{...}
};

这个时候，LoggingMsgSender:

1
2
3
4
5
6
7
8
9
10
11
12
13

template<typename Company>
class LoggingMsgSender : public MsgSender<Company>
{
public:
	...
	void sendClearMsg(const MsgInfo& info)
	{
		...	//	发送前记日志
		sendClear(info);		// 调用Company == CompanyZ时候，基类就不提供sendClear()函数了
		... //	发送后记日志
	}
	...
};

因为MsgSender有可能存在全特化的版本，因而编译器不会去处理基类相关的内容。

为了能够正常编译代码，有三个办法(假设所有的Company行为一致，不会像CompanyZ有与众不同的行为):

• 用this关键字

  1 2 3 4 5 6 7 8 9 10 11 12 13

  template<typename Company> class LoggingMsgSender : public MsgSender<Company> { public: ... void sendClearMsg(const MsgInfo& info) { ... // 发送前记日志 this->sendClear(info); // 告诉编译器这个函数是类成员，强迫编译器从整个继承体系搜索 ... // 发送后记日志 } ... };

• 用using声明式:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  template<typename Company> class LoggingMsgSender : public MsgSender<Company> { public: using MsgSender<Company>::sendClear; // 告诉编译器假定sendClear由基类提供 ... void sendClearMsg(const MsgInfo& info) { ... // 发送前记日志 sendClear(info); // 假设sendClear存在于基类，则编译通过 ... // 发送后记日志 } ... };

• 显式指出函数的版本:

  1 2 3 4 5 6 7 8 9 10 11 12 13

  template<typename Company> class LoggingMsgSender : public MsgSender<Company> { public: ... void sendClearMsg(const MsgInfo& info) { ... // 发送前记日志 MsgSender<Company>::sendClear(info); // 告诉编译器用MsgSender<Company>::sendClear ... // 发送后记日志 } ... };

  第二三个方法显式地声明了函数，会使得virtual函数的多态行为失效。

还有，如果采用了解决方案之后，还出现LoggingMsgSender<CompanyZ>的实例化，编译当然就失败了。

条款44:将与参数无关的代码抽离templates

该条款第一个提到的问题是非参数类型带来的代码膨胀，template支持如下的语法:

1
2
3

template<typename T, std::size_t size>	// 假设该类为size*size大小的方阵
class SquareMatrix
{...};

在写下:

1
2
3
4
5

SquareMatrix<int, 3> m1;

SquareMatrix<int, 4> m2;

...

编译器会为SquareMatrix<int, 3>以及SquareMatrix<int, 4>模板类各自生成实例，可能产生如下的代码:

1
2
3
4
5
6
7
8
9
10
11

class I3SquareMatrix
{
public:
	...
};

class I4SquareMatrix
{
public:
	...
};

当需要产生很多大小不一的方阵实例的时候，类模板的实例代码随之膨胀。然而仅仅只是因为尺寸的问题就带来代码膨胀，这是不必要的。通过成员变量一般可以解决问题:

1
2
3
4
5
6
7
8
9
10
11

template<typename T>
class SquareMatrix
{
public:
	...
private:
	...
	std::size_t matrix_size;		// 通过一个成员变量记录方阵的大小
	T* data_ptr;					// 存储实际数据的指针，也可以是T**类型
	...
};

这样就解决了来自于非参数类型导致的代码膨胀。

而对于来自与类型参数的代码膨胀，一般不需要处理，要么就要有高超的编程技巧。例如SquareMatrix<int>、SquareMatrix<const int>和SquareMatrix<long>明明在二进制表示上一致(一般平台int和long一样)，但是编译器会分别为它们生成不同的类模板实例。往往这样做的话需要用到void*类型来操作一些手法，这个就是很底层的代码的问题了，而且STL大部分容器是做了这个优化的，因而笔者认为该部分大多数人了解即可。

条款45:运用成员函数模板接受所有兼容类型

书上用了智能指针来作说明，如下一个继承体系:

1
2
3
4
5

class Top {...};

class Middle : public Top {...};

class Bottom : public Middle {...};

第一版的智能指针类定义:

1
2
3
4
5
6
7

template<typename T>
class SmartPtr
{
public:
	explicit SmartPtr(T* ptr);	// 提供原生的指针进行初始化
	...
};

原生的继承体系，用父类的指针指向子类实例:

1
2
3

Top* top1 = new Middle;

Top* top2 = new Bottom;

都没有任何问题，但是:

1
2
3
4
5
6
7
8
9
10

void fun(SmartPtr<Top> top)
{
	// 处理一些只与Top类型相关的操作
}

...

SmartPtr<Middle> middlePtr(new Middle);	// 假定开发者在这个作用域知道实际的类型

fun(middlePtr);				// 根据继承体系，传入一个Middle实例应该是没问题的

但是问题就出现在这里了，原生的继承体系Top<-Middle<-Bottom是没有问题的，一般的编译器会为上面的使用生成如下的类模板实例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 模板的实例化
class TopSmartPtr			// 为SmartPtr<Top>生成的模板类
{
public:
	explicit TopSmartPtr(Top* ptr);
	...
};

class MiddleSmartPtr			// 为SmartPtr<Middle>生成的模板类
{
public:
	explicit MiddleSmartPtr(Middle* ptr);
	...
};

注意并不是:

1
2

class MiddleSmartPtr : public TopSmartPtr
{...};

也就是说SmartPtr<Middle>与SmartPtr<Top>没有任何关系，目前也没有代码提供它们之间的显式或者隐式类型转换，自然编译不能通过了。

为了解决这个问题，让SmartPtr<Top> top(SmartPtr<Middle>(new Middle))这类的语法能够正常工作，SmartPtr的类定义则应该这么写:

1
2
3
4
5
6
7
8
9
10
11

template<typname T>
class SmartPtr
{
public:
	template<typename U>
	explicit SmartPtr(U* instance);		// T兼容U，例如例子中的继承关系

	template<typename U>
	SmartPtr& operator=(const SmartPtr<U>& sptr);	// 兼容类型的复制函数
	...
};

更具体的设计可以查看std::shared_ptr的源码，在这里要提示一点，在写下上面的成员函数的定义时，应该是:

1
2
3
4
5
6

template<typename T>
	template<typename U>		// 笔者习惯加个缩进表示U参数是在T参数的作用域内
SmartPtr<T>& operator=(const SmartPtr<U>& sptr)
{
	...					// 实现代码
}

而不能写成不能通过的:

1
2
3
4
5

template<typename T, typename U>
SmartPtr<T>& operator=(const SmartPtr<U>& sptr)
{
	...					// 实现代码
}

这样就解决了泛化的问题。

条款46:需要类型转换时请为模板定义非成员函数

问题类似与条款24,不同的是这次加入了模板，假设有个有理数的类模板:

1
2
3
4
5
6
7
8
9
10
11
12
13

template<typename T>
class Rational
{
public:
	Rational(const T& numerator = 0, const T& denominator);		// 条款20
	const T numerator() const;					// 条款28
	const T denominator() const;				// 条款3
	...
};

template<typename T>
const Rational<T> operator*(const Rational<T>& lhs, const Rational<T>& rhs)
{...}

根据常理，有理数直接的操作:

1
2
3

Rational<int> oneHalf(1, 2);

Rational result = oneHalf * 2;

应该是没问题的，但是在强类型语言中，编译器试图寻找匹配的函数，但是目前也只能匹配到:

1
2

template<typename T>
const Rational<T> operator*(const Rational<T>& lhs, const Rational<T>& rhs)

显然根据地一个参数，Rational<int>被推导出来了，然而template实参推导过程不会考虑通过构造函数而发生的隐式类型转换。在编程人员尚未提供规则使得int可以向const Rational<int>转换，在产生模板函数过程自然推导失败了。

书上提供的解决方法:

1
2
3
4
5
6
7
8
9
10
11
12

template<typename T>
class Rational
{
public:
	...
	// 将operator*重载变为类的友元函数
	friend const Rational operator*(const Rational& lhs, const Rational& rhs);
};

template<typename T>
const Rational<T> operator*(const Rational& lhs, const Rational& rhs)
{...}

这样做的原理是让编译器在产生Rational<int>类模板实例时，带上友元函数一起产生，使其省略上一个版本让编译器先为operator*推导的步骤，然后迫使oneHalf * 2套用函数时，对int强制做隐式类型转换。

编译通过，但是会链接失败，神奇的是，把operator*的定义放回类内部又可以了:

1
2
3
4
5
6
7
8
9
10

template<typename T>
class Rational
{
public:
	...
	friend const Rational operator*(const Rational& lhs, const Rational& rhs)
	{
		...	// 函数定义
	}
};

friend关键字原本是用于让类外部的函数，或者类，可以访问私有成员，但是这里并没有这样的使用。

当类模板相关的函数需要隐式类型转换的时候，将函数定义为类模板内部的friend函数。

条款47:请使用traits classes表现类型信息

这个条款对于写轮子的人来说比较有用，STL用的人应该不少，但是阅读过STL源码的人可能不多，连笔者至今也没有系统读过C++ STL的源码，而STL中才会有大量涉及traits classes代码。

Traits并不是C++关键字或者一个预先定义好的构建:它们是一种技术，也是一个C++程序员共同遵守的协议。

因为模板编程的初衷是将与类型无关的操作提取出来，减少代码的重复性。不从实现角度来讨论，在该条款里面，模板编程表现得像接口一样，引用书上advance函数的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// advance作为一个STL算法实现，作用是让迭代器向前移动d步
// DistT是距离变量的类型
template<typename IterT, typename DistT>
void advance(IterT& iter, DistT d)
{
	if(iter是一个随机访问的迭代器)
	{
		iter += d;	// 直接跳d步
	}
	else
	{
		if(d >= 0){while(d--) ++iter;}		// 一步一步跳d步
		else {while(d++) --iter;}			// 当d小于0时是回退d步
	}
}

在advance例子里面，if分支里面的描述用到的就是输入的迭代器的Traits信息，假设迭代器的遵循Traits协议:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

template<typename IterT>
struct IteratorTraits			// Traits通常用struct做实现
{
	const static bool is_random_access = false;		// 在特化前，所有的迭代器默认没有随机访问的能力
	...							// 其他有关迭代器的Traits描述
};

...

template<>				// 全特化，假定存在RandomAccessIterator这个类
struct IteratorTraits<RandomAccessIterator>	// 针对该迭代器特化一个模板
{
	const static bool is_random_access = true;		// 该类迭代器具备随机访问能力
	...					// 其他Traits描述
};

有了类似这样的实现，那么上面的advance例子的判断语句可以具体为:

1

if(IterT::is_random_access)

这时的advance就像是一个接口，你只需要输入兼容的迭代器即可，无需关心该迭代器的特性会影响如何完成这个操作。

笔者前面的模拟实现是需要运行时的判断，而模板元编程强大之处，也是设计思想，尽可能地在编译期完成计算，提高运行时的效率。那么Traits应该改成较为合理的形式(参考STL):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

template<...>		// 省略参数
class deque			// STL中的双向队列
{
public：
	class iterator 	// 双向队列自带的迭代器实现
	{
		typedef random_access_iterator_tag iterator_category;	// 说明自己的分类是随机迭代器
		...
	};
	...
};

// 根据上面STL中提供的迭代器定义，可以简单地提取其中自带的Traits信息，一般的实现
template<typename IterT>
struct iterator_traits 
{
	typedef typename IterT::iterator_category iterator_category;		// 说明自身是何种迭代器的traits
	...
};

可以根据STL的设计，提供一个运行时的判断:

1
2
3
4
5
6
7
8