透彻了解inline以及降低编译依存关系
透彻了解inline以及降低编译依存关系
inline内敛
1.类似于C中的#define
在C++中，提供了inline函数来代替C中的宏定义。（通常可以使用const来代替单纯变量的宏定义，它可以提供类型检查。对于形似函数的宏，最好改用inline函数来替换宏定义。）
编译器最优化机制通常被设计用来浓缩那些“不含函数调用“的代码，所以当你inline某个函数时，或许编译器就因此有能力对它执行语境相关最优化。
2.效率问题
inline函数同#define宏定义一样，都是以函数本体做替换，这样做可能增加你的目标码（object code），从而可能造成代码膨胀（代码膨胀会导致额外的换页行为，降低指令高速缓存装置的击中率，带来效率损失）。
如果inline函数本体很小，编译器针对“函数本体”所产生的码可能比针对“函数调用”所产生的码可能更小。
3.是申请，而不是强制，也不一定要带inline
注意，inline只是对编译器的一个申请，不是强制命令。这项申请可以 隐喻 提出，也可以明确提出：
class person{
public :
int age() const { return m_age; } // 隐喻提出inline申请
private :
int m_age;
};
4.虚函数可以inline吗？
大部分编译器都回拒绝太复杂的inline函数，而对所有的virtual虚函数都不能申请为inline函数，这是因为虚函数意味着”等待，直到运行期间才能确定调用哪个函数“，而inline意味着”执行前，先将调用动作替换为函数本体“。
5.构造函数和析构函数一般不应该是inline的
通常在继承类中，即使是空的构造函数和析构函数，也会调用基类的构造函数和析构函数，如果是多重继承的话代码就会更加复杂。这样如果再把它设为inline函数的话，出现的地方都回替换函数本体，那代码量务必会增加的。
6.templates函数不一定要inline
templates通常放在头文件中，编译器将它具现化才能知道函数本体的内容。inline需要成本，所以要多加考虑，否则可能导致代码膨胀。
7.程序升级与inline函数
inline函数无法随程序库的升级而升级，故需要升级的函数不要采用inline函数。
假如f是一个inline函数，这时如果把f编进程序中，一旦程序决定修改f函数，所有用到f的客户端程序都必须重新编译，这往往是不被接受的。如果是非Inline函数，一旦它有修改升级，程序只需要编译这部分重新连接就好。
降低文件间的编译依存关系
C++没有把接口从实现中分离出来，为了实现接口与实现的分离，要使用声明式，不要使用定义式。基于此构想的两个手段是handle classes和interface classes。
int main()
{
int x;
Person p( params );
}
当编译器看到x的定义式，它知道必须分配多少内存才能够容下一个int。但当编议器看到p的定义式，如何知道一个person有多大？唯一的办法就是询问class的定义式。然而如果class定义式不列出实现的细节，该怎么办？
int main ()
{
int x;
Person * p;
}
只定义一个指向Person对象的指针。这里将不需要class的定义式，如果class Person的任何修改都不需要从新编译这个函数文件。
也就是说，通过声明的依赖性替代定义的依赖性，来实现接口与实现的分离。
所以需要注意 ：
如果使用object reference或object pointers能完成的任务，就不要使用object。references 和pointers只依靠类型声明式，但object就要依靠类型的定义式了。
如果可以，尽量以class声明式替换class定义式。
不知道从何时开始，在这里记笔记已经成为了一个习惯，不记下来总觉得就忘记了
标签: C++
作者： Leo_wl
出处： http://HdhCmsTestcnblogs测试数据/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息查看更多关于透彻了解inline以及降低编译依存关系的详细内容...