Effective STL_ch外文书.pdf

前言 Center of STL Study ——最优秀的STL学习网站 前言 It came without ribbons! It came without tags! It came without packages, boxes or bags! ——Dr. Seuss,How the Grinch Stole Christmas!, Random House, 1957 STL》。 我把这个想法忍了几年。一开始，我对STL不够熟悉，所以不能给出关于它的建议。但随着时间的推移，我 STL的经验丰富了，而主要问题出现在了其他方面。当一个程序库的在效率和可扩展性设计上表现出突破性 的时候从来没有出过什么问题，但当开始使用STL时，这成了我无法预见的实际问题。迁移到一个几乎最简 单的STL程序都成了一个挑战，不光是因为库的实现变化多端，而且因为现有编译器对模板支持有好有坏。 STL的教材很难得到，所以学习“STL的编程方式”很难；但即使跨越了这个障碍，找到正确易学的参考文档 同样很困难。可能最令人畏惧的是，即使最小的STL使用错误也往往会导致一个编译器诊断的风暴——每一 个错误都有上千个字长，而且大多涉及的类，函数或模板在令人厌恶的源代码中并没有被提及——几乎都是 难以理解的。虽然我很钦佩STL和它背后的英雄们，但我还是觉得把STL推荐给实践中的程序员并不合适。我 不能肯定有可能有效地使用STL。 然后我开始注意到一些让我感到惊奇的事情。尽管有很多小问题，尽管只有令人消沉的文档，尽管编译器的 诊断信息像无线电信号杂音，但仍然有很多我的咨询客户在使用STL。而且，他们不只是玩玩而已，他们竟 然把STL用到了产品的代码中！这是一个革命。我知道STL表现出的是一流的设计，但任何让程序员必须忍受 移植性的麻烦、贫乏的文档和天书般的错误信息，却设计得很好的库也是不会被拥护的。我了解到越来越多 的专业程序员都认为即使一个实现得很不好的STL也比什么都没有要好得多。 此外，我知道STL的境遇只会越来越好。程序库和编译器对（它们的）标准兼容性会越来越好，更好的文档 参考书目”），而且编译器的诊断会渐渐改进（在极大程 将会出现（它已经存在了——请见从297页开始的“ 度上，我们仍然在等待，但条款49提供了怎样在其间应付的建议）。因此我决定插嘴，尽一份力量来支持 STL运动的萌芽。这本书就是结果：改善使用C++ STL的50个有效做法。 一开始，我计划在1999年下半年写这本书。带着这个想法，我组织了一个大纲。但我暂停和改变了进程。我 前言 停止了写书的工作，开发了一个介绍性的STL训练课程，把它教给几拨不同的程序员。大约一年后，我回到 践方面——这是对专业开发人员最重要的方面。 我总是在寻找能让我加深对C++理解的方法。如果你对STL编程有新的建议或者如果你对这本书有什么评论 的话，请让我知道。另外，让本书尽可能地正确是我继续的目标，所以如果谁挑出了本书的任何一个错误请 务必告诉我——不论是技术、语法、错别字或任何其他东西——我将在本书再次印刷的时候，把第一位挑出 错误的读者大名加到致谢名单中。请将你的建议、见解、批评发至 estl@。 我维护有本书第一次印刷以来的修订记录，其中包括错误更正、文字修润、以及技术更新。这份记录可以从 《Effective STL》的勘误表网站 得到。 如果你希望在我对此书作出修改时得到通知，我想你应该加入我的邮件列表。我用这个列表来通知对我的C+ +工作感兴趣的人。详情请见 /MailingList/。 SCOTT DOUGLAS MEYERS STAFFORD, OREGON APRIL 2001 致谢 致谢 在我理解STL、建立关于它的培训课程和写这本书的大约两年时间里，我得到了大量帮助。在我所有帮助的 而且我从他那里比从其他人那里学到更多关于STL的东西。他也作为本书的技术评论家，再次提供改进了几 乎每个条款的观点和见解。 物的帮助。 多种出版物形成了我对STL的理解，其中最重要的列在了参考书目 Library》 [3]倾向特别大。 本书基本上是其他人做的一些见解和观点的摘要，虽然有一些想法是我自己的。我已经努力跟踪我在哪里学 到了什么，但这个任务是没希望的，因为一个典型的条款包含在很长时间内从很