条款30 透彻了解inlining的里里外外

/*条款30 透彻了解inlining的里里外外*/
//1 过度热衷inlining会造成程序体积太大
//2 inline只是对编译器的一个申请，不是强制命令，可以隐喻提出，可以明确提出
//3 大多数的inlining都是在编译期完成，少部分是在连接期完成，更少数是在运行期完成
//4 每种编译器评估是否可以做为inlining的标准并不一致，大部分编译器，拒绝循环，递归，虚函数（虚函数在运行期才确定调用个哪个函数）

#include<iostream>
using namespace std;

class Person {
public:
	int age()const {//隐喻inline申请
		return theAge;
	}
private:
	int theAge;
};
class Base {
public:
	//..
private:
	std::string bm1, bm2;
};
class Derived :public Base {
public:
	Derived(){}//Derived构造函数是空的，哦，是吗？
	//看起来是个内联的绝佳人选
private:
	std::string dm1, dm2, dm3;
};
/*
下面是Derived构造函数产生的代码 
Derived::Derived(){
	Base::Base();                //初始化Base成分
	try{dml.std::string::string();//试图构造dm1
	catch(..){                   // 如果抛出异常
		Base::~Base();          // 销毁base class 成分 并throw
		throw;
	}
	try{dm2.std:;string::string();}
	catch(..){
		dm1.std::string::~string();
		Base::~Base();
		throw;
	}
	try{dm3.std:;string::string();}
	catch(..){
		dm2.std::string::~string();
		dm1.std::string::~string();
		Base::~Base();
		throw;
	}
	子类构造函数至少一定会陆续调用其成员变量与基类两者的构造函数
	而这些调用会影响编译器是否对此空白函数内联
	相同也适用于基类的构造函数，如果基类构造被内联，那么基类构造
	的函数调用的代码会插入到子类的构造中
	如果string构造函数恰巧被内联，Derived构造函数将会有五份string
	构造函数的副本（两个继承，三个自己的）


	程序设计者必须评估“将函数声明为inline”的冲击
	inline函数无法随着程序库的升级而升级
	就是说如果f是程序库的一个inline函数，客户将f函数本体编进程序中
	一旦程序设计者决定改变f,所有用到f的客户端程序必须重新编译

	另外内联的函数无法进行断点调试

	不要只因为函数模板出现在头文件，就将它们声明为inline 考虑函数具体行为
	*/
inline void f() {}
int main() {
	void(*pf) () = f;
	f();//正常调用 inlined
	//5 通过函数指针进行调用的Inline函数，调用时可能并不是inlined形式的调用
	pf();//无法内联
	system("pause");
	return 0;
}