STL学习之路：Effective STL 中文版解读

需积分: 17 30 浏览量更新于2024-07-19 1 收藏 7.37MB PDF 举报

"Effective STL 中文版 - 最优秀的STL学习网站" Effective STL 是一本由Scott Meyers撰写的书籍，旨在帮助C++程序员更好地理解和利用标准模板库（STL）。这本书的创作源于作者在1995年对STL的初步探讨，并在之后的年份里积累了丰富的经验，逐渐形成了对STL使用的实用建议。 STL是C++编程中一个极其重要的组成部分，它包括容器（如vector, list, set等）、迭代器、算法和函数对象。STL的设计理念是提供高效、灵活且可重用的代码，使得程序员能够处理数据结构和算法问题，而无需关注底层的实现细节。然而，STL的学习曲线相对陡峭，主要原因在于： 1. **实现多样性**：不同编译器和库实现之间的差异可能导致相同代码在不同环境下的行为不一致，增加了移植的复杂性。 2. **模板支持**：早期的编译器对模板支持有限，可能导致编译错误难以理解和解决。 3. **文档不足**：STL的文档通常不够详尽，学习和查找参考资料困难。 4. **编译器诊断**：STL的模板错误信息通常很长且难以理解，给调试带来挑战。尽管存在这些问题，Meyers发现许多专业程序员仍在实践中积极采用STL。他们不仅适应了这些挑战，还通过STL实现了高效、可维护的代码。这表明，STL的益处，如性能提升和代码复用，远超过了其学习和使用上的困难。 Effective STL 提供了一系列的准则和最佳实践，帮助程序员克服上述难题，主要包括以下几点： - **理解STL容器的内部工作机制**：例如，知道vector在何时进行动态扩展，以及这些扩展如何影响性能。 - **有效使用迭代器**：迭代器是STL的核心，理解其生命周期、遍历规则和操作方式至关重要。 - **选择合适的算法**：STL提供了大量的算法，如排序、搜索和变换，理解它们的效率和适用场景可以提高代码性能。 - **自定义函数对象**：利用函数对象（functors）可以创建定制的行为，增强算法的功能。 - **避免常见的陷阱和误区**：书中会揭示一些常见的错误和陷阱，以及如何避免它们。通过深入研究Effective STL，读者可以提升对STL的掌握，编写出更加高效、可读和可靠的C++代码。这本书对于那些希望充分利用STL潜力的专业程序员来说，是一份不可或缺的指南。

Center of STL Study

——最优秀的STL学习网站

条款条款6：警惕：警惕C++最令人恼怒的解析最令人恼怒的解析

假设你有一个int的文件，你想要把那些int拷贝到一个list中。这看起来像是一个合理的方式：

ifstream dataFile("ints.dat");

list<int> data(istream_iterator<int>(dataFile), // 警告！这完成的并不

istream_iterator<int>()); // 是像你想象的那样

这里的想法是传一对istream_iterator给list的区间构造函数（参见条款5），因此把int从文件拷贝到list中。

这段代码可以编译，但在运行时，它什么都没做。它不会从文件中读出任何数据。它甚至不会建立一个list。那是因为第二句并不声明list，而且它也不调用构造函

数。其实它做的是……，它做得很奇怪。我不敢直接告诉你，因为你可能不相信我。取而代之的是，我得一点一点展开这个解释。你坐下了吗？如果没有，你可

能要找找附近有没有椅子……

我们会从最基本的开始。这行声明了一个函数f带有一个double而且返回一个int：

int f(double d);

第二行作了同样的事情。名为d的参数左右的括号是多余的，被忽略：

int f(double (d)); // 同上；d左右的括号被忽略

下面这行声明了同样的函数。它只是省略了参数名：

int f(double); // 同上；参数名被省略

你应该很熟悉这三种声明形式了吧，虽然可以把括号放在参数名左右这一点可能比较新。（在不久以前我也觉得它新。）

现在让我们再看看三个函数声明。第一个声明了一个函数g，它带有一个参数，那个参数是指向一个没有参数、返回double的函数的指针：

int g(double (*pf)()); // g带有一个指向函数的指针作为参数

这是完成同一件事的另一种方式。唯一的不同是pf使用非指针语法来声明（一个在C和C++中都有效的语法）：

int g(double pf()); // 同上；pf其实是一个指针

照常，参数名可以省略，所以这是g的第三种声明，去掉了pf这个名字：

int g(double ()); // 同上；参数名省略

注意

参数名左右

的括号（就像f的第二种声明中的d）和

单独的

括号（正如本例）之间的区别。参数名左右的括号被忽略，但单独的括号指出存在一个参数列表：

它们声明了存在指向函数的指针的参数。

用这些f和g的声明做了热身，我们准备检查本条款开头的代码。这里再写一遍：

list<int> data(istream_iterator<int>(dataFile), istream_iterator<int>());

打起精神，这声明了一个函数data，它的返回类型是list<int>。这个函数data带有两个参数：

第一个参数叫做dataFile。它的类型是istream_iterator<int>。dataFile左右的括号是多余的而且被忽略。

第二个参数没有名字。它的类型是指向一个没有参数而且返回istream_iterator<int>的函数的指针。

奇怪吗？但这符合C++里的一条通用规则——几乎任何东西都可能被分析成函数声明。如果你用C++编程有一段时间了，你应该会遇到另一个这条规则的表象。

有多少次你会看见这个错误？

class Widget {...}; // 假设Widget有默认构造函数

Widget w(); // 嗯哦……

这并没有声明一个叫做w的Widget，它声明了一个叫作w的没有参数且返回Widget的函数。学会识别这个

失言（

faux pas

）

是成为C++程序员的一个真正的通过仪

式。

所有这些都很有趣（以它自己的扭曲方式），但它没有帮我们说出我们想要说的，也就是应该用一个文件的内容来初始化一个list<int>对象。现在我们知道了我们

必须战胜的解析，那就很容易表示了。用括号包围一个实参的声明是不合法的，但用括号包围一个函数调用的观点是合法的，所以通过增加一对括号，我们强迫

编译器以我们的方式看事情：

list<int> data((istream_iterator<int>(dataFile)), // 注意在list构造函数

istream_iterator<int>()); // 的第一个实参左右的

// 新括号

Center of STL Study

——最优秀的STL学习网站

条款条款7：当使用：当使用new得指针的容器时，记得在销毁容器前得指针的容器时，记得在销毁容器前delete那些指针那些指针

STL中的容器非常优秀。它们提供了前向和逆向遍历的迭代器（通过begin、end、rbegin等）；它们能告诉你所容纳的对象类型（通过value_type的typedef）；在

插入和删除中，它们负责任何需要的内存管理；它们报告容纳了多少对象和最多可能容纳的数量（分别通过size和max_size）；而且当然当容器自己被销毁时会

自动销毁容纳的每个对象。

给了这样聪明的容器，很多程序员不再担心用完以后的清除工作。呵呵，他们说，他们的容器会帮他们解决那个麻烦。在很多情况下，他们是对的，但当容器容

纳的是指向通过new分配的对象的指针时，他们就错了。的确，当一个指针的容器被销毁时，会销毁它（那个容器）包含的每个元素，但指针的“析构函数”是无操

作！它肯定不会调用delete。

结果，下面代码直接导致一个内存泄漏：

void doSomething()

{

vector<Widget*> vwp;

for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)

vwp.push_back(new Widget);

... // 使用vwp

} // Widgets在这里泄漏！

当vwp除了生存域后，vwp的每个元素都被销毁，但那并不改变从没有把delete作用于new得到的对象这个事实。那样的删除是你的职责，而不是vector的。这是一

个特性。只有你知道一个指针是否

应该

被删除。

通常，你需要它们被删除。当情况如此时，可以很简单地实现：

void doSomething()

{

vector<Widget*> vwp;

... // 同上

for (vector<Widget*>::iterator i = vwp.begin();

i != vwp.end(),

++i) {

delete *i;

}

这可以工作，除非你不是对你“工作”的意思很吹毛求疵。一个问题是新的for循环代码比for_each多得多，但没有使用for_each来的清楚（参见条款43）。另一个问

题是这段代码不是异常安全的。如果在用指针填充了vwp和你要删除它们之间抛出了一个异常，你会再次资源泄漏。幸运的是，两个问题都可以克服。

要把你的类似for_each的循环转化为真正使用for_each，你需要把delete转入一个函数对象中。这像儿戏般简单，假设你有一个喜欢和STL一起玩的孩子：

template<typename T>

struct DeleteObject : // 条款40描述了为什么

public unary_function<const T*, void> { // 这里有这个继承

void operator()(const T* ptr) const

{

delete ptr;

}

};

现在你可以这么做：

void doSomething()

{

... // 同上

for_each(vwp.begin(), vwp.end(), DeleteObject<Widget>);

}

不幸的是，这让你指定了DeleteObject将会删除的对象的类型（在本例中是Widget）。那是很讨厌的，vwp是一个vector<Widget*>，所以当然DeleteObject会删

除Widget*指针！咄！这种冗余就不光是讨厌了，因为它会导致很难跟踪到的bug。假设，比如，有的人恶意地故意从string继承：

class SpecialString: public string { ... };

这是很危险的行为，因为string，就像所有的标准STL容器，缺少虚析构函数，而从没有虚析构函数的类公有继承是一个大的C++禁忌。（详细信息参考任意好的

C++书。在《Effective C++》中，要看的地方是条款14。）但是，仍有一些人做这种事，所以让我们考虑一下下面代码会有什么行为：

void doSomething()

{

deque<SpecialString*> dssp;

...

for_each(dssp.begin(), dssp.end(), // 行为未定义！通过没有

DeleteObject<string>()); // 虚析构函数的基类

} // 指针来删除派生对象

注意dssp被声明为容纳SpecialString*指针，但for_each循环的作者告诉DeleteObject它将删除string*指针。很容易知道会出现什么样的错误。SpecialString的行

为当然很像string，所以如果它的用户偶尔忘了他们用的是SpecialStrings而不是string是可以原谅的。

你可以通过编译器推断传给DeleteObject::operator()的指针的类型来消除这个错误（也减少DeleteObject的用户需要的击键次数）。我们需要做的所有的事就是把

模板化从DeleteObject移到它的operator()：

struct DeleteObject { // 删除这里的

// 模板化和基类

template<typename T> // 模板化加在这里

void operator()(const T* ptr) const

{

delete ptr;

}

编译器知道传给DeleteObject::operator()的指针的类型，所以我们可以让它通过指针的类型自动实例化一个operator()。这种类型演绎下降让我们放弃使

DeleteObject可适配的能力（参见条款40）。想想DeleteObject的设计目的，会很难想象那会是一个问题。

使用新版DeleteObject，用于SpecialString的客户代码看起来像这样：

void doSomething()

{

deque<SpecialString*> dssp;

...

for_each(dssp.begin(), dssp.end(),

DeleteObject()); // 啊！良好定义的行为！

}

直截了当而且类型安全，正如我们喜欢的一样。

但仍不是异常安全的。如果在SpecialString被new但在调用for_each之前抛出一个异常，就会发生泄漏。那个问题可以以多种方式被解决，但最简单的可能是用智

能指针的容器来代替指针的容器，典型的是引用计数指针。（如果你不熟悉智能指针的概念，你应该可以在任何中级或高级C++书上找到描述。在《More

Effective C++》中，这段材料在条款28。）

STL本身没有包含引用计数指针，而且写一个好的——一个总是可以正确工作的——非常需要技巧，除非必须否则你一定不想做。我在1996年的《More Effective

C++》中发布了用于引用计数智能指针的代码，尽管是基于已制定的智能指针实现并提交给由有经验的开发人员做了很多发布前检查，小bug报告还是持续了很多

年。智能指针出错的不同方式的数量很值得注意。（详细信息请参考《More Effective C++》错误列表[28]。）

幸运的是，基本上不需要你自己写，因为经过检验的实现不难找到。一个这样的智能指针是Boost库（参见条款50）中的shared_ptr。利用Boost的shared_ptr，

本条款的原始例子可以重写为这样：

void doSomething()

{

typedef boost::shared_ ptr<Widget> SPW; //SPW = "shared_ptr

// to Widget"

vector<SPW> vwp;

for (int i = 0; i < SOME_MAGIC_NUMBER; ++i)

vwp.push_back(SPW(new Widget)); // 从一个Widget建立SPW,

// 然后进行一次push_back

... // 使用vwp

} // 这里没有Widget泄漏，甚至

// 在上面代码中抛出异常

你不能有的愚蠢思想是你可以通过建立auto_ptr的容器来形成可以自动删除的指针。那是很可怕的想法，非常危险。我在条款8讨论了为什么你应该避免它。

我们需要记住的所有事情就是STL容器很智能，但它们没有智能到知道是否应该删除它们所包含的指针。当你要删除指针的容器时要避免资源泄漏，你必须用智

能引用计数指针对象（比如Boost的shared_ptr）来代替指针，或者你必须在容器销毁前手动删除容器中的每个指针。

最后，你可能会想到既然一个类似DeleteObject的结构体可以简化避免容纳对象指针的容器资源泄漏，那么是否可能建立一个类似的DeleteArray结构体来简化避

免容纳指向数组的指针的容器资源泄漏呢？这当然

可能

，但是否明智则不是同一回事了。条款13解释了为什么动态分配数组几乎总是劣于vector和string对象，所

以在你要写DeleteArray之前，请先看看条款13。运气好的话，你会知道DeleteArray是永远不会出现的结构体。

Center of STL Study

——最优秀的STL学习网站

条款条款8：永不建立：永不建立auto_ptr的容器的容器

坦白地说，本条款不需要出现在《Effective STL》里。auto_ptr的容器（COAPs）是禁止的。试图使用它们的代码都不能编译。C++ 标准委员会花费了无数努力

来安排这种情况

[1]

。我本来不需要说有关COAPs的任何东西，因为你的编译器对这样的容器应该有很多抱怨，而且所有那些都是不能编译的。

唉，很多程序员使用STL平台不会拒绝COAPs。更糟的是，很多程序员妄想地把COAPs看作简单、直接、高效地解决经常伴随指针容器（参见条款7和33）资源

泄漏的方案。结果，很多程序员被引诱去使用COAPs，即使建立它们不应该成功。

我会马上解释COAPs的幽灵有多令人担心，以至于标准化委员会采取特殊措施来保证它们不合法。现在，我要专注于一个不需要auto_ptr甚至容器知识的缺点：

COAPs不可移植。它们能是怎么样的？C++标准禁止他们，比较好的STL平台已经实现了。可以有足够理由推断随着时间的推移，目前不能实现标准的这个方面

的STL平台将变得更适应，并且当那发生时，使用COAPs的代码将更比现在更不可移植。如果你重视移植性（并且你应该是），你将仅仅因为它们的移植测试失

败而拒绝COAPs。

但可能你没有移植性思想。如果是这样，请允许我提醒你拷贝auto_ptr的独特——有的人说是奇异——的定义。

当你拷贝一个auto_ptr时，auto_ptr所指向对象的所有权被转移到拷贝的auto_ptr，而被拷贝的auto_ptr被设为NULL。你正确地说一遍：

拷贝一个

auto_ptr

将改变它

的值

：

auto_ptr<Widget> pw1(new Widget); // pw1指向一个Widget

auto_ptr<Widget> pw2(pw1); // pw2指向pw1的Widget;

// pw1被设为NULL。（Widget的

// 所有权从pw1转移到pw2。）

pw1 = pw2; // pw1现在再次指向Widget；

// pw2被设为NULL

这非常不寻常，也许它很有趣，但你（作为STL的用户）关心的原因是它导致一些非常令人惊讶的行为。例如，考虑这段看起来很正确的代码，它建立一个

auto_ptr<Widget>的vector，然后使用一个比较指向的Widget的值的函数对它进行排序。

bool widgetAPCompare(const auto_ptr<Widget>& lhs,

const auto_ptr<Widget>& rhs) {

return *lhs < *rhs; // 对于这个例子，假设Widget

} // 存在operator<

vector<auto_ptr<Widget> > widgets; // 建立一个vector，然后

// 用Widget的auto_ptr填充它；

// 记住这将

不能

编译！

sort(widgets.begin(), widgets.end(), // 排序这个vector

widgetAPCompare);

这里的所有东西看起来都很合理，而且从概念上看所有东西也都很合理，但结果却完全不合理。例如，在排序过程中widgets中的一个或多个auto_ptr可能已经被

设为NULL。排序这个vector的行为可能已经改变了它的内容！值得去了解这是怎么发生的。

它会这样是因为实现sort的方法——一个常见的方法，正如它呈现的——是使用了快速排序算法的某种变体。我们不关心快速排序的妙处，但排序一个容器的基

本思想是，选择容器的某个元素作为“主元”，然后对大于和小于或等于主元的值进行递归排序。在sort内部，这样的方法多多少少看起来像这样：

template<class RandomAccessIterator, // 这个sort的声明

class Compare> // 直接来自于标准

void sort(RandomAccessIterator first,

RandomAccessIterator last,

Compare comp)

{

// 这个typedef在下面解释

typedef typename iterator_traits<RandomAccessIterator>::value_type

ElementType;

RandomAccessIterator i;

... // 让i指向主元

ElementType pivotValue(*); // 把主元拷贝到一个

// 局部临时变量中；参见

// 下面的讨论

... // 做剩下的排序工作

}

除非你是在阅读STL源代码方面很有经验，否则这看起来可能有些麻烦，但其实并不坏。唯一的难点是引用了

iterator_traits<RandomAccessIterator>::value_type，而只不过是传给sort的迭代器所指向的对象类型的怪异的STL方式。（当我们涉及

iterator_traits<RandomAccessIterator>::value_type时，我们必须在它前面写上typename，因为它是一个依赖于模板参数类型的名字，在这里是

RandomAccessIterator。更多关于typename用法的信息，翻到第7页。）

上面代码中棘手的是这一行，

剩余148页未读，继续阅读

杨逸

粉丝: 0
资源: 2

STL学习之路：Effective STL 中文版解读

Effective STL 中文版：C++编程精华指南

快速掌握C++ STL：Effective STL中文版详解

EffectiveSTL中文版：STL编程的实践指南

Effective STL中文版

EFFECTIVE STL中文版

effective stl 中文版

effective stl中文版+英文版

Effective STL 中文版.chm

Effective STL中文版.CHM

Effective STL 中文版(完整版)

最新资源