More Effective C++之服从Efficiency_中

条款19：相识临时对象的泉源

    步伐员攀谈的时间，通常把一个短暂须要的变量称为“临时变量”。比方下面的swap函数：

1. template <class T>
2. void swap(T& object1, T& object2) {
3.         T temp = object1;
4.         object1 = object2;
5.         objec2 = temp;
6. }

复制代码

    常有人将temp称为一个临时对象（“temporary”）。但是在C++眼中，temp并不是临时对象，它只是函数中的一个局部对象。
    C++真正的所谓的临时对象是不可见的——不会在我们的源码中出现。只要我们产生一个no-heap object而没有为它定名，便诞生了一个临时对象。此匿名对象通常发生于两种情况：一是隐式范例转换（implicit type conversions）被施行起来以求函数调用可以或许乐成；二是当函数返回对象的时间。相识这些临时对象怎样（以及为什么）被产生和烧毁，是很告急的，由于其陪伴的构造本钱和析构本钱大概对我们的步伐性能带来值得注意的影响。
    起首思量“为了让函数调用乐成”而产生的临时对象。此乃发生于“通报某对象给一个函数，而其范例于它既定绑定上去的参数范例差异”的时间。比方，思量一个函数，用来盘算字符串中某字符出现的次数：

1. // 返回ch在str中出现的个数
2. size_t countChar(const string& str, char ch);
4. char buffer[MAX_STRING_LEN];
5. char c;
7. // 读入一个char和一个string，利用setw避免在读入string时产生缓存区溢出的情况
8. cin >> c >> setw(MAX_STRING_LEN) >> buffer;
10. cout << "There are " << countChar(buffer, c)
11.                 << " occurrences of the character " << c
12.                 << " in " << buffer << endl;

复制代码

    请看countChar的调用动作。其第一自变量是char数组，但是相应的函数参数范例却是const string&。当“范例不符合”的状态消除，此函数调用才会乐成；编译器很乐意消除此状态，做法是产生一个范例为string的临时对象。该对象的初始化方式是：以buffer作为自变量，调用string constructor。于是countChar的str参数会被绑定于此string临时对象上。当countChar返回，此临时对象会被自动烧毁。
    如许的转换很方便（固然也很伤害——见条款5），但是从服从角度观之，一个string临时对象的构造和析构，有其非须要的本钱。有两个做法可消除此种转换，一是重新计划代码，使这类转换不会发生，此战略验证于条款5；另一个做法就是修改软件，使这种转换不在须要，条款21将形貌这种做法。
    只有当对象——by value（传值）方式通报，或是当对象被通报给一个reference-to-const参数时，这些转换才会发生。假如对象被传给一个reference-to-non-const参数，并不会产生此类转换。思量这个函数：

1. void uppercasify(string &str);                                                                                                // 将str中的所有chars改为大写

复制代码

    在上一个（盘算字符个数）例子中，我们可以乐成地将一个字符数组通报给countChar，但是在这里，将一个字符数组交给uppercasesify会导致调用失败：

1. char subtleBookPlug[] = "Effective C++";
2. uppercasify(subtleBookPlug);                                                                                                // 错误！

复制代码

    不再有任何临时对象被产生出来以玉成此函数的调用。为什么？
    假设编译器为此产生一个临时对象，然后此临时对象被通报给uppercasify，以便将此中的字符串全部修改为大写。此函数的实元——subtleBookPlug——并未受到影响，只有以subtleBookPlug为本所产生的谁人string临时对象受到影响。这固然不是步伐员所瞻仰的结果。步伐员将subtleBookPlug传给uppercasify，就是盼望subtleBookPlug被修改。当步伐员盼望“非临时对象”被修改，此时假如编译器针对reference-to-non-const对象举行隐式范例转换，会允许临时对象被修改。这就是为什么C++语言克制为non-const reference参数产生临时对象的缘故起因。Reference-to-const参数则不须要负担此标题，由于此参数由于const之故，无法被改变。
    第二种会产生临时对象的情况是当函数返回一个对象时。比方，operator+必须返回一个对象，表现其操纵数的总和。假设有一个Number范例，其operator+声明如下：

1. const Number operator+(const Number& lhs, const Number& rhs);

复制代码

    此函数返回值是一个临时对象，由于它没闻名称：它就是函数的返回值，云云而已。每当我们调用operator+，便得为此对象付出构造和析构本钱。
    一样平常而言我们不会想要负担这份本钱。对于此特殊函数，我们可以改用一个雷同的函数operator+=免掉这份本钱。条款22将会详述这种做法。但是对其他“返回对象”的函数而言，大多数难以被另一个函数替换，以是没办法克制返回值构造和析构。至少，观念上没办法。但是观念和实物之间，有一个名为“优化”的黝黯地带，偶然间我们可以以某种方式撰写“返回值为一个对象”的函数，使编译器得以将临时对象优化，使它不复存在。在这些优化战略中，最常见也是最有用的就是所谓的“返回值优化（return value optimization”，那正是条款20的主题。
    结论是：临时对象大概很耗本钱，以是我们应该尽大概消除它们。然后更告急的是，怎样练习出锐利的眼力，看出大概产生临时对象的地方。任何时间只要我们看到一个reference-to-const参数，就极大概会有一个临时对象被产生出来绑定至该参数上。任何时间只要我们看到函数返回一个对象，就会产生临时对象（并于稍后烧毁）。学习找出这些模式，我们对幕后本钱（编译器举动）的洞察力将会有显着提拔。
学习心得
    本条款告诉我们临时对象为在函数调用及返回过程中的不具名对象，此临时对象在不经意间会调用对象的构造和析构函数。特殊须要注意在函数参数为reference-to-const范例时，隐式转化会特殊埋伏的构造临时对象，以是须要特殊注意此情况的产生；另一个情况则为返回对象为非引用，此时不可克制的会产生临时对象，此时我们的思绪是怎样积极淘汰临时对象产生的个数。亦即条款20会先容的返回值优化方法。
条款20：帮忙完成“返回值优化（RVO）”

    函数假如返回对象，对“服从狂”而言是一个严峻的挫败，由于——by-value方式返回对象，背后隐蔽的constructor和destructor都将无法消除。标题很简单：假如为了举动准确而不得不如许，函数可返回一个对象；否则就不要那么做。假如真的决定返回对象，那就没有任何办法可以摆脱“返回一个对象”所会遭遇的运气。
    思量分数（rational numbers）的operator*函数：

1. class Rational {
2. public:
3.         Rational(int numerator = 0, int demominator = 1);
4.         ...
5.         int numerator() const;
6.         int demominator() const;
7. };
8. const Rational operator*(const Rational& lhs, const Rational& rhs);

复制代码

    乃至不必看operator的函数代码，我们也知道它必须返回一个对象，由于它返回两个恣意数的乘积，operator怎样可以或许在不产生新对象的情况下放置该乘积呢？不大概，以是它必须产生一个新对象并将它返回。只管云云，C++步伐员却像希腊神话中赫克里斯一样，淹灭巨大的积极筹划探求消除“by-value返回方式”的神奇方法。
    偶然间人们会返回指针，为求克制返回对象。

1. const Rational* operator*(const Rational& lis, const Rational& rhs);
2. Rational a = 10;
3. Rational b(1, 2);
4. Rational c = *(a * b)；                                                                                                // 这看起来不太自然

复制代码

    别的它还引出另一个标题：调用者应该删除此函数返回的指针吗？答案通常是yes，而那通常会导致资源泄漏（resource leaks）。
    另一些步伐员大概返回references，于是导出一个可被担当的语法情势：

1. const Rational& operator* (const Rational& lis, const Rational& rhs);
2. Rational a = 10;
3. Rational b(1, 2);
4. Rational c = a * b；                                                                                                // 看起来很合理自然

复制代码

    但是如许的函数却根本无法有准确的举动。常见的做法是：

1. // 一个危险（而且不正确）的做法，为避免返回对象
2. const Rational& operator* (const Rational& lis, const Rational& rhs) {
3.         Rational result(lhs.numberator() * rhs.numberator(),  lhs.demominator() * rhs.demominator());
4.         return result;
5. }

复制代码

    此函数返回一个reference，指向一个不在存活的对象。更明白地说，它返回一个reference，指向局部对象result，但result却在operator*返回时自动烧毁了。返回一个reference却指向一个不再存活的对象，很像一个指针指向了被烧毁的对象。
    请信赖：有些函数（比方，operator*）硬是得返回对象。它就必须云云，别对它宣战，不会赢的。
    也就是说，假如函数肯定得以by-value方式返回对象，我们绝对无法消除之。这是一场错误的战争。从服从的眼光来看，我们不应该在乎函数返回了一个对象，应该在乎的是谁人对象的本钱多少。积极找出某种方法低沉被返回对象的本钱，而不是想尽办法消除对象自己。假如如许的对象不须要本钱，谁在乎产生多少个呢？
    我们可以用某种特殊写法来撰写函数，使它在返回对象时，可以或许让编译器消除临时对象的本钱。我们的本事是：返回所谓的constructor arguments以代替对象。我们可以这么做：

1. // 返回一个对象：一个效率且正确的做法
2. const Rational operator* (const Rational& lis, const Rational& rhs) {
3.         return Rational(lhs.numberator() * rhs.numberator(),  lhs.demominator() * rhs.demominator());
5. }

复制代码

    请细致看看被返回的表达式。看起来好像是我们调用了Rational constructor，究竟上也简直是。通过此表达式，我们产生了一个Rational临时对象：

1. Rational(lhs.numberator() * rhs.numberator(),  lhs.demominator() * rhs.demominator());

复制代码

    而函数复制此临时对象，当做返回值。
    以constructor arguments代替局部对象，当做返回值，这笔交易好像不见得多么划算，由于我们照旧必须为“函数内的临时对象”的构造和析构付出代价，我们照旧必须为“函数返回对象”的构造和析构付出代价。但是我已经赚到了某些东西。C++允许编译器将临时对象优化，使它们不存在。于是假如如许调用operator*：

1. Rational a = 10;
2. Rational b(1, 2);
3. Rational c = a * b;                                                                                                // 这里调用了operator*

复制代码

    编译器得以消除“operator内的临时对象”及“被operator返回的临时对象”。它们可以将return表达式所界说的对象构造于c的内存内。假如编译器这么做，调用operator*时的临时对象总本钱为0，也就是没有任何临时对象须要被产生出来。取而代之的是，只须要付出一个constructor（用以产生c）的代价。我们无法做得比这更好了，由于c是一个定名对象，而定名对象时不能被消除的。我们可以将此函数声明为inline，以消除调用operator*所耗费的额外开销：

1. //  函数返回一个对象：最有服从的做法inline const Rational operator* (const Rational& lis, const Rational& rhs) {        return Rational(lhs.numberator() * rhs.numberator(),  lhs.demominator() * rhs.demominator());
2. }

复制代码

    此特殊的优化举动——利用函数的return点消除一个局部临时对象（并大概用函数调用端的某对象代替）——不但广为人知而且很普各处被实现出来。它乃至有个专属名称：return value optimization。“拥有专属名称”这一究竟足以反映出它是多么被广泛应用。步伐员在探求理想的C++编译器时，不妨扣问厂商是否支持return value optimization。假如A厂商有，而B厂商反问“那是什么？”，A厂商有显着的竞争上风。
学习心得
    此条款，告诉我们假如某函数须要返回对象，假如有办法用其他方式如指针大概引用可代替的话，优先用替换的方法；由于假如返回的是对象，不可克制的会导致临时对象的产生；对于临时对象的产生，同时也提供了return value optimization方法，在return语句后产生临时对象；云云，可以让编译器顺遂的举行优化，将大概得开销降到最低（只调用唯一的一次构造函数constructor）。
条款21：利用重载技能（overload）克制隐式范例转换（implicit type conversions）

    以下代码，除了看起来极为公道之外，没什么特殊：

1. class UPInt {                                                                                                                // 这个class用于无限精密的整数
2. public:
3.         UPInt();
4.         UPInt(int value);
5.         ...
6. };
7. const UPInt operator+(const UPInt& lhs, const UPInt& rhs);
8. UPInt upi1, upi2;
9. ...
10. UPInt upi3 = upi1 + upi2;

复制代码

    没有什么值得惊奇的地方。upi1和upi2都是UPInt对象，以是只须要调用UPInt的operator+便可将它们加在一起。
    现在思量以下语句：

1. upi3 = upi1 + 10；
2. upi3 = 10 + upi2；

复制代码

    这些句子也能乐成。它们之以是能乐成，是由于产生了临时对象，并将整数10转换为UPInts。
    由编译器来实行此类转换，很方便，但是此类转换所产生的临时对象带来了一些我们并不想要的本钱。大部分C++步伐员盼望得到隐式范例转换，却不盼望遭受临时对象所带来的本钱。
    我们可以退回一步，认可我们的目的并非真正在于范例转换，而是盼望一个UPInt自变量和一个int自变量调用operator+。只不外隐式范例转换是一种本事罢了，千万不要把目的和本事肴杂了。假如有其他做法可以让operator+在自变量范例稠浊的情况下别调用乐成，那便消除了范例转换的需求。假如我们盼望可以或许对UPInt和int举行加法，我们须要做的就是将我们的意图告诉编译器，做法是声明数个函数，每个函数有差异的参数表：

1. const UPInt operator+(const UPInt& lhs, const UPInt& rhs);const UPInt operator+(const UPInt& lhs,  int rhs);const UPInt operator+(int lhs, const UPInt& rhs);UPInt upi1, upi2;...UPInt upi3 = upi1 + upi2;upi3 = upi1 + 10；
2. upi3 = 10 + upi2；

复制代码

    上述代码的三次operator+调用都不会产生UPInt临时对象。
    一旦开始以重载技能消除范例转换，我们大概会热情地进一步写出以下函数声明：

1. const UPInt operator+(int lhs, int rhs);                                                                                // (4)错误！

复制代码

    如许的想法原是颇为公道的。究竟面对范例UPInt和int，我们盼望将operator+的全部大概组合都予以重载。上述3中组合之外，唯一遗漏的就是“得到两个int自变量”的operator+，以是我们要加上它。
    岂论是否公道，C++存在很多游戏规则，此中一个就是：每个“重载操纵符”必须得到至少一个“用户定制范例”的自变量。int不是用户定制范例，以是我们不可以或许将一个只得到int自变量的操纵符加以重载。（假如这个规则不存在，步伐员可以改变预先界说的操纵符意义，而那固然会导致天下大乱。比方，上述的operator重载版本(4),会改变ints的加法意义。岂非这真是我们所盼望的吗？）
    “用以克制产生临时对象”的此等重载技能，并不但范围运用在操纵符函数身上。比方，在大部分步伐中，假如可以担当一个char*，我们大概会盼望也担当一个string对象，反之依然。同样的原理，假如我们正在利用一个数值雷同complex，应该会盼望该数值对象可出现的任何所在，也都可以或许有用运用范例int和double。因此，任何函数假如担当范例为string，char*，comple等自变量，都可以借由重载技能，公道消除范例转换。
    不外，请不要忘了，80-20法则（见条款16）照旧很告急的。增长一大堆重载函数不见得是件功德，除非我们有好的来由信赖，利用重载函数后，步伐的团体服从可得到巨大的改善。
学习心得
    此条款，给出了一种通过重载函数（包罗操纵符、函数等）的方式，来消除隐式范例转换的方法。同时表明白该方法并不是银弹，由于重载函数大概会导致步伐代码变大，导致其他引起性能低沉的大概。以是我们须要酌情思量在隐式范例转换确实会造成大的代价的情况下，才利用该条款举行重载处置惩罚。
条款22：思量以操纵符复合情势（op=)代替其独体态式（op）

    大部分步伐员都盼望，假如他们可以或许如许写：

1. x = x + y;                                                                                                                        x = x - y;

复制代码

    他们也可以或许写成如许：

1. x += y;                                                                                                                                x -=y;

复制代码

    假如x和y属于定制范例，就不包管肯定可以或许云云。到现在为止C++并不思量在operator+，operator=和operator+=之间设立任何互动关系。以是假如我们盼望这3个操纵符都存在而且有着所盼望的互动关系，必须自己实现。操纵符-，*，/也是一样。
    要确保操纵符的复合情势（比方，operator+=）和其独体态式（比方，operator+）之间的天然关系可以或许存在，一个好方法就是从前者作为根本实现后者。这很容易做到：

1. class Rational {
2. public:
3.         ...
4.         Rational& operator += (const Rational& rhs);
5.         Rational& operator -= (const Rational& rhs);
6. };
7. const Rational operator+(const Rational& lhs, const Rational& rhs) {
8.         return Rational(lhs) += rhs;
9. }
10. const Rational operator-(const Rational& lhs, const Rational& rhs) {
11.         return Rational(lhs) -= rhs;
12. }

复制代码

    此例中的operator+=和operator-=都是重新做起的，而operator+和operator-则是调用前者以供应它们所需的性能。假如采取这种计划，那么这些操纵符之中就只有复合情势才须要维护，别的，假如这些操纵符的复合情势是在class的public接口内，那么就不须要让独体态式成为该class的friends。
    假如不介意把全部独体态式操纵符放在全局范围内，我们可以利用templates，完全消除独体态式操纵符的撰写须要：

1. template<class T>
2. const T operator+(const T& lhs, const T& rhs) {
3.         return T(lhs) += rhs;
4. }
5. template<class T>
6. const T operator-(const T& lhs, const T& rhs) {
7.         return T(lhs) -= rhs;
8. }
9. ...

复制代码

    有了这些templates之后，只要步伐中针对范例T界说有一个复合操纵符，对应的独身版本就会在须要的时间被自动产生出来。
    这些都很好，但是到现在为止我们还没有思量服从标题，而服从究竟是本章的主题。3个与服从有关的情况值得注意。第一，一样平常而言，复合操纵符比其对应的独身版本服从高，由于独身版本通常必须返回一个新对象，而我们必须因此负担一个临时对象的构造和析构本钱。至于复合版本则是直接将结果写入左端自变量，以是不须要产生一个临时对象来放置返回值。
第二，假如同时提供某个操纵符的复合情势和独体态式，便允许客户在服从与便利性之间做弃取（固然那是极其困难的决定）。也就是说，客户可以绝对是否写如许的代码：

1. Rational a, b, c, d, result;
2. ...
3. result = a + b + c + d;                                                                                                                // 可能会用到3个临时对象，每一个对应一次operator+的调用

复制代码

    或是如许的代码：

1. result  = a;
2. result += b;                                                                                                                                // 不需要临时对象                                                                                                                                                                        
3. result += c;                                                                                                                                // 不需要临时对象
4. result += d;                                                                                                                                // 不需要临时对象

复制代码

    前者较易撰写、调试、维护。并在80%的时间内供应足可担当的性能。后者服从较高，而且（大概）对汇编语言步伐员比力直观。假如同时供应两种选择，我们便允许客户以较易明白的操纵符独身版原来发展步伐并调试，而同时仍生存“将独身版本用更有服从的复合版本代替”的权利。别的，借由“以复合版本作为独身版本的实现根本”，我们可以确保，当客户以某种选择改变为另一种选择时，操纵语法仍保持稳固。
    我们把末了一个服从观察放在独体态式操纵符身上。再次看看operator+实现码：

1. template<class T>
2. const T operator+(const T& lhs, const T& rhs)
3. { return T(lhs) += rhs; }

复制代码

    表达式T(lhs)是个调用动作，调用T的copy constructor。它会产生一个临时对象，其值和lhs雷同。这个临时对象然后被用来调用operator+=，并以rhs作为自变量，运算结果则被operator+返回。这段代码好像过于艰涩，如许写岂非不更好吗：

1. template<class T>
2. const T operator+(const T& lhs, const T& rhs){
3.         T result(lhs);
4.         return result += rhs;
5. }

复制代码

    比大部分编译器所能担当的“返回值优化”情势更为复杂。前述第一个template大概须要在函数内斲丧一个临时对象，就像利用定名对象result本钱一样。然而，自古以来匿名对象总是比定名对象更容易被消除，以是劈面对定名对象或临时对象的决定时，最好选择临时对象。它应该绝不会比其定名兄弟耗用更多本钱。反倒是极有大概低沉本钱（尤其是搭配旧式编译器时）。
    定名对象、匿名对象、编译器优化等干系讨论度相称风趣，但是我们不要忘了本条款的主题：操纵符的“复合版本”（比方，operator+=）比其对应的“独身版本”（比方，operator+）有着更高服从的倾向。身为以为步伐库计划者，我们应该两者都提供；身为以为软件开发者，假如性能是告急因素的话，我们应该思量以“复合版本”操纵符代替其“独身版本”。
学习心得
    本条款，针对操纵符复合情势（op=)代替其独体态式（op），从性能及实在现方式上做了叙述；发起我们起首实现复合情势(op=),然后独体态式通过调用复合情势的方式，以提拔代码的可维护性（只须要维护复合情势即可）；同时，为了步伐库的通用性，发起将复合情势和独体态式都提供，但是自己在写服从优先的软件时，优先通过复合情势来提拔体系性能。
条款23: 思量利用其他步伐库

    步伐库的计划，可说是一种折中态度的练习。理想的步伐库应该小、快速、威力强盛、富弹性、有扩展性、直观、可广泛运用、有良好支持、利用时没有束缚，而且没有bug。固然，如许的东西是不存在的。假如针对巨细和速率做优化，便通常不具移植性。假如拥有丰富的性能，就不容易直观。没有bug的步伐库只能在乌托邦中探求。真实天下中险些不大概拥有每一样东西，某些东西必须弃取。
    差异的计划者面对这些规范给予差异的优先权。他们的计划各有差异的断送。于是，很容易出现“两个步伐库提供雷同性能，却有相称差异的性能表现”的情况。
    举个例子。思量iostream和stdio步伐库，任何一位C++步伐员对这两者应该都不陌生。iostream步伐库较其C兄弟有数个长处，比方，它具有范例安全（type-safe)特性，而且可扩充。然而服从方面iostream通常表现得比stdio差，由于stdio的可实行文件通常比iostreams更小也更快。
    让我们先思量速率。想要对iostreams和stdio之间的性能差异有一些感觉，办法之一就是利用这两个步伐库来实行性能评估软件（所谓benchmark）。但很告急的一点是，请记着，性能评估软件会说谎。“以一组输入数据作为步伐或步伐库的范例用途”不但是件困难的事，就算有如许的数据，也是没用的，除非我们有一个可信任的方法足以决定客户的“范例”程度。只管云云，性能评估软件照旧可以再“差异做法之间的性能比力”上助我们一臂之力。以是固然完全依赖性能评估软件是很愚笨的举动，但完全忽略它也是一样愚笨。
    让我们查验一个极为简单的性能评估软件，它只测试最根本的I/O性能。这个步伐从尺度输入装备读取30000个浮点数，然后以固定格式将它们写到尺度输出装备。步伐就是采取iostream或是stdio，由预处置惩罚符号STDIO来决定——在编译期就做决定。假如这个符号有界说，就利用stdio步伐库，否则就利用iostream步伐库。

1. #ifedf STDIO
2. #include <stdio.h>
3. #else
4. #include <iostream>
5. #include <iomanip>
6. using namespace std;
7. #endif
9. const int VALUES = 30000;
10. int main() {
11.         double d;
12.         for (int n = 1; n <= VALUES; ++n) {
13. #ifdef STDIO
14.                 scanf("%lf", &d);
15.                 printf("%10.5f", d);
17. #else
18.                 cin >> d;
19.                 cout << setw(10)
20.                                 << setprecision(5)
21.                                 << setiosflags(ios::showpoint)
22.                                 << setiosflags(ios::fixed)
23.                                 << d;
24. #endif
26.                 if (n % 5 == 0) {
27. #ifdef STDIO
28.                         printf("\n");
29. #else
30.                         cout << "\n";
31. #endif
32.                 }
33.         }
34.         return 0;
35. }

复制代码

    iostream的以下情势：

1. cout << setw(10)
2.                 << setprecision(5)
3.                 << setiosflags(ios::showpoint)
4.                 << setiosflags(ios::fixed)
5.                 << d;

复制代码

    并不像下面这行那么易读易写：

1. printf("%10.5f", d);

复制代码

    但是operator<<不但范例安全而且可扩充，而printf两者皆否。
    本例利用差异的呆板、差异的操纵体系、差异的编译器来测试这个步伐。无论哪种组合，stdio版都比力快，偶然间只是快一点（约莫20%），偶然间则是快很多（险些到达200%），但从未测出iostream版比stdio版更快的情况。别的这个平庸无奇的步伐的可实行文件巨细，stdio版本比iostream版小（偶然间小很多）。不外对于一个真正有用的步伐而言，两者所造成的可实行文件巨细差异应该不大。
    请记着，stdio所具备的任何服从上风都和其产物高度相依，以是未来所测试的产物，或现在存在而未曾测试的产物，都有大概造成iostreams和stdio之间的性能差异小到可以忽略。究竟上，我们可以公道地盼望找到一个iostream产物，速率表现比stdio更快，由于iostreams在编译期就决定其操纵数的范例，而stdio函数则是在运行时期才气分析其格式字符串（format string）。
    然后，iostream和stdio之间的性能对比只是个例子，不是重点。重点是，差异的步伐库纵然提供相似的技能，也通常表现出差异的性能弃取战略，以是一旦我们找出步伐的瓶颈（通太过析器），我们应该思索是否有大概由于改用另一步伐库而移除那些瓶颈。假如步伐有一个I/O瓶颈，可以思量以stdio代替iostream，但假如步伐耗费很多时间在动态内存分配和开释方面，大概应该看看是否有其他提供了operator new和operator delete的步伐库产物。由于差异的步伐库将服从、扩充性、移植性、范例安全性等的差异计划具体化，偶然间可以找找看是否存在另一个功能相近的步伐库而其服从上有较高的计划权重。假如有，改用它，可大幅改善步伐性能。
学习心得
    本条款，通过给出iostream和stdio库的性能对比，向我们保举了步伐性能优化过程中，假如发现性能瓶颈点在步伐库的时间，不妨试试新的库更换方案（创建在步伐的分析profiler根本上）。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。