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