###《Effective STL》--Chapter7

点击查看Evernote原文。

#@author:       gr
#@date:         2014-08-31
#@email:        forgerui@gmail.com

Chapter7 在程序中使用STL

Topic 43: 算法调用优先于手写的循环

　　调用STL算法可以一次性达到想要的结果，减少中间过程资源时间的消耗，除此之外，编译器可能对一些算法进行了优化，比自己写循环更高效。

Topic 44: 容器的成员函数优先于同名的算法

　　算法实现的时候为了保证算法的通用性，不会针对每种结构进行单独的优化，而使用容器的成员函数则可以针对这种容器进行优化。比如有些成员函数的时间复杂度可能为log(N)，而通用算法可能会达到线性时间N，这种情况很常见。

Topic 46: 考虑使用函数对象而不是函数作为STL算法的参数

　　使用函数对象，可以对函数进行内联，这样会减少额外的函数调用开销，同时，可以对函数进行重载，满足通用性要求。而使用函数，只能定义成一种函数指针形式，这样不利于扩展。

Topic 47: 避免“直写型代码”

　　复杂语句很难懂，代码阅读的次数远远大于它被编写的次数，所以将复杂语句分解成更易于理解的简单语句，并且适当加上一些注释。

Topic 48: 总是包含(#include)正确的头文件

  1. 任何时候使用某一个头文件中的STL组件，你就应该包含这个头文件，即使当前的编译器允许你省略#include指令。当你移植到其它平台时，你的努力就会得到回报。

  2. 几乎所有容器都包含在其同名的头文件中，如vector包含在<vector>中，list包含在<list>中；但<set>中同时声明了set和multiset，同理<map>也是。

  3. 除了4个STL算法以外，所有其他算法都在<algorithm>中，这4个算法是accumlate、inner_product、adjacent_difference和partial_sum，它们被声明在<numeric>中。

  4. 特殊的迭代器，包括istream_iterator和ostream_iterator被声明在<numeric>中。

  5. 标准的函数子(比如less<T>)和函数子配接器(比如not1、bind2nd)被声明在<functional>中。

Topic 49: 学会分析与STL相关的编译器诊断信息

  1. 了解错误的源头
    使用string时的错误
    //string报错的语句
    string s(10);

    可能会报一些关于一长串关于std::basic_string<>的错误，看起来很混乱。这是因为，string并不是一个类，而是一个typedef，它可能是下面的basic_string实例的类型定义，当然有的编译器可能是其它的方式：
    basic_string<char, char_traits, allocator >

    所以可以将这一长串错误替换成string这样就变得清晰了。

  2. 尝试使用简单的类型去替换复杂的错误类型，从而简化错误信息，发现错误的原因。

  3. vector和string的迭代器就是指针，所以当使用iterator出错时，编译器的诊断信息中可能会引用到指针类型。比如，如果源代码中引用vector<double>::iterator出错，编译器中很可能提到double*。

  4. 如果你得到的错误来源于某一个STL算法的内部实现，可能是在调用算法时候，使用了错误的类型。

  5. 如果你正在使用一个很常见的STL组件，如vector、string或for_each算法，但是错误信息看起来好像编译器一无所知，那么可能是没有包含头文件。

Topic 50: 熟悉与STL相关的Web站点

posted @ 2014-09-29 10:54  bairuiworld  阅读(281)  评论(0)  编辑  收藏  举报