C++代码优化（1）

        经常能看到论坛上讨论C++好还是JAVA好，哪个效率高等等，其实作为编程语言，它们必有自己存在的价值，在某一领域发挥着它们的作用。可以说一个C++菜鸟写出来的程序的性能肯定没有一个JAVA老手写出来的程序的性能好，可见程序性能的好坏是要看程序员的功力。最近在看《提高C++性能的编程技术》，边看边把一些有用的技巧整理一下写到博客上。

（1）缓式构造

        往往性能的优化经常需要牺牲一些其他软件目标，诸如灵活性、可维护性、可扩展性、成本、重用之类的。解决了性能问题，或者说生成了高质量的代码，而不危及其他软件开发目标的情况是很少见的，但是有些情况下我们可以调整代码消除一些开销，如一些对象创建了却从来不会用到。

一种代码风格是在代码块的开头定义好要用到的数据类型，在C++中自然而然地预先定义好所有对象的习惯是一种浪费，如下代码所示，对象a只在b为真的时候才需要使用，b为假的时候，a完全没用到，这就是一种冗余的开销，应该把a移到if里面去。

A a;
if(b)
{
        a.run();
}

C程序员趋向于在函数块的开头定义所有变量时有依据的，因为C变量定义没有运行时的开销。尽管有了C++语言开始，C++专家就一直呼吁要把变量创建延迟到第一次使用时，但是这种编码错误仍会在实际产品代码中发现..

（2）冗余构造

        考虑一下如下类Person中的构造函数，用一个char 指针s赋值给标准库中的string变量name。看看这构造函数到底做了什么：所包含的成员变量string name没有出现在构造函数得初始化列表中，因此为了正确的初始化string成员变量，编译器必须插入一个调用，以调用string的默认构造函数，然后name = s这条语句调用了string::operator(const char *)，因此先前调用string默认构造函数可以说是冗余的。

class Person
{
public:
	Person(const char *s){name = s;}
	...
private:
	string name;
};

把Person构造函数改成Person(const char *s) : name(s){}，这样在初始化string name的时候会调用string::string(const char *)这个重载带一个参数的构造函数，但是这相对于前一种构造函数来说仅有略微的提升，因为默认的string构造函数是非常廉价的从而使这种低效几乎可以忽略不计，但是这种细节却是一种良好的编程习惯。

        现在我们决定用自己的一个类SuperString来代替原Person类中的string。Super类的声明如下，实现的就累述了，可参照标准库string的实现。这个类我们只有一种版本的SuperString & operator = (const SuperString & s)，参数为SuperStirng的引用。

class SuperString
{
public:
	SuperString(const char *s = null);
	SuperString(const SuperString &s);
	SuperString & operator = (const SuperString & s);
	~SuperString();
private:
	char *str;
}

        当在Person的构造函数中name = s做了什么事情呢：先调用name的默认构造函数，再创建一个临时的SuperString对象_temp来满足赋值操作符，调用_temp的参数为char指针的构造函数，然后调用赋值操作符把_temp赋给name，最后调用_temp的析构函数。如果我们在SuperString中重载一个赋值操作符来满足参数char *s，则这个临时变量的创建析构的开销可以完全去掉，或者直接用初始化参数表，以char *s来初始化SuperString也可以消除这个冗余的开销。

Person::Person(const char *s)
{
	name.SuperString::SuperString();
	
	SuperString _temp;
	_temp.SuperString::SuperString(s);
	
	name.SuperString::operator = (_temp);
	_temp.SuperString::~SuperString();
}

（3）总结

        对象的生命周期不是无偿的。对象的创建和清楚会消耗CPU周期。除非打算要使用一个对象，否则就不要创建它。通常情况下，要把对象的创建推迟到要使用它的块中。

        要确保所编写的代码实际使用了所以创建的对象和这些对象所执行的计算，例如一些临时对象的创建是否可以消除。鼓励程序员进入他们所使用的类。这个建议不会受到OOP鼓吹者的欢迎。毕竟OOP的鼓吹者使用要像封装黑匣子实体一样，不鼓励人们看到内幕。有的应用程序重视可维护性和灵活性，而另外一些应用程序则有可能把性能放在最为重要的位置，作为程序员，应当清楚到底该把哪个方面最大化。