EffectiveSTL

前言 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 我第一次写关于标准模板库的东西是在1995年，那时我决定把《More Effective C++》的最后一个条款写成一个STL的简要概览。我早该更好 地了解STL。不久以后，我开始收到一些邮件，问我什么时候写 《Effective STL》。 我把这个想法忍了几年。一开始，我对STL不够熟悉，所以不能给出关 于它的建议。但随着时间的推移，我STL的经验丰富了，而主要问题出 现在了其他方面。当一个程序库的在效率和可扩展性设计上表现出突破 性的时候从来没有出过什么问题，但当开始使用STL时，这成了我无法 预见的实际问题。迁移到一个几乎最简单的STL程序都成了一个挑战， 不光是因为库的实现变化多端，而且因为现有编译器对模板支持有好有 坏。STL的教材很难得到，所以学习“STL的编程方式”很难；但即使跨 越了这个障碍，找到正确易学的参考文档同样很困难。可能最令人畏惧 的是，即使最小的STL使用错误也往往会导致一个编译器诊断的风暴 ——每一个错误都有上千个字长，而且大多涉及的类，函数或模板在令 人厌恶的源代码中并没有被提及——几乎都是难以理解的。虽然我很钦 佩STL和它背后的英雄们，但我还是觉得把STL推荐给实践中的程序员 并不合适。我不能肯定有可能 有效地使用STL。 然后我开始注意到一些让我感到惊奇的事情。尽管有很多小问题，尽管 只有令人消沉的文档，尽管编译器的诊断信息像无线电信号杂音，但仍 然有很多我的咨询客户在使用STL。而且，他们不只是玩玩而已，他们 竟然把STL用到了产品的代码中！这是一个革命。我知道STL表现出的 是一流的设计，但任何让程序员必须忍受移植性的麻烦、贫乏的文档和 天书般的错误信息，却设计得很好的库也是不会被拥护的。我了解到越 来越多的专业程序员都认为即使一个实现得很不好的STL也比什么都没 有要好得多。 此外，我知道STL的境遇只会越来越好。程序库和编译器对（它们的） 标准兼容性会越来越好，更好的文档将会出现（它已经存在了——请见 从297页开始的“参考书目 ”），而且编译器的诊断会渐渐改进（在极大 程度上，我们仍然在等待，但条款49 提供了怎样在其间应付的建 议）。因此我决定插嘴，尽一份力量来支持STL运动的萌......