关于C 代码优化的方法总结

当然有一点应该意识到，inline specifier仅仅是对编译器的建议，编译器有权利忽略这个建议。那么编译器是如何决定函数内联和否呢？一般情况下关键性因素包括函数体的大小，是否有局部对象被声明，函数的复杂性等等。

　　2．那么假如一个函数被声明为inline但是却没有被内联将会发生什么呢？理论上，当编译器拒绝内联一个函数的时候，那个函数会像普通函数相同被对待，但是还会出现一些其他的问题。例如下面这段代码：

　　// filename Time.h

　　#include<ctime>

　　#include<iostream>

　　using namespace std;

　　class Time

　　{

　　ublic:

　　inline void Show() { for (int i = 0; i<10; i )

　　cout<<time(0)<<endl;}

　　};

　　因为成员函数Time::Show()包括一个局部变量和一个for循环，所以编译器一般拒绝inline，并且把他当作一个普通的成员函数。但是这个包含类声明的头文档会被单独的#include进各个单独的编译单元中：

　　// filename f1.cpp

　　#include "Time.hj"

　　void f1()

　　{

　　Time t1;

　　t1.Show();

　　}

　　// filename f2.cpp

　　#include "Time.h"

　　void f2()

　　{

　　Time t2;

　　t2.Show();

　　}

　　结果编译器为这个程式生成了两个相同成员函数的拷贝：

　　void f1();

　　void f2();

　　int main()

　　{

　　f1();

　　f2();

　　return 0;

　　}

　　当程式被链接的时候，linker将会面对两个相同的Time::Show()拷贝，于是函数重定义的连接错误发生。但是老一些的C 实现对付这种情况的办法是通过把一个un-inlined函数当作static来处理。因此每一份函数拷贝仅仅在自己的编译单元中可见，这样链接错误就解决了，但是在程式中却会留下多份函数拷贝。在这种情况下，程式的性能不但没有提升，反而增加了编译和链接时间连同最终可执行体的大小。

　　但是幸运的是，新的C 标准中关于un-inlined函数的说法已改变。一个符合标准C 实现应该只生成一份函数拷贝。然而，要想任何的编译器都支持这一点可能还需要很长时间。

　　另外关于内联函数更有两个更令人头疼的问题。第一个问题是该如何进行维护。一个函数开始的时候可能以内联的形式出现，但是随着系统的扩展，函数体可能需要

　　添加额外的功能，结果内联函数就变得不太可能，因此需要把inline specifier去除连同把函数体放到一个单独的源文档中。另一个问题是当内联函数被应用在代码库的时候产生。当内联函数改变的时候，用户必须重新编译他们的代码以反映这种改变。然而对于一个非内联函数，用户仅仅需要重新链接就能够了。

　　这里想要说的是，内联函数并不是个增强性能的灵丹妙药。只有当函数很短小的时候他才能得到我们想要的效果，但是假如函数并不是很短而且在很多地方都被调用的话，那么将会使得可执行体的体积增大。最