1. 在设计原则上，STL和Boost大体统一
因为STL和Boost基本上都是标准委员会那批人在策划、审核和维护，所以口味上是相对接近的。
但是因为Boost并不在标准中，或者说是下一代标准的试验场，所以库的种类要更多一些，手法也更加丰富一些。
2. STL/Boost 针对 Developer 和 User 的要求不同
对于Boost开发者而言，强调的是代码可读、高效、强调元编程和编程技巧。
补注：评论里面果然有人提到说可读性和元编程有矛盾。这种说法大概类似于“这段代码可读性差是因为业务太复杂”。这是不对的。可读性是要建立在正确的满足功能和性能的基础上的。这也是为什么我要特别为后两点解（Jiao）释（Bian）一下。
这里要解释一下后两点：
- 编程技巧主要是为了实现一些看起来有点像天方夜谭的功能，例如C++11之前的Boost.Auto（利用了编译器的Bug或者特性）；以及1.56才加入的TypeIndex，该宏利用了编译器能产生Mangled/Demangled函数签名的能力。
- 元编程主要是为了解决三个问题：
- 增加宏/模板演算的能力，为图灵完备的模板编程提供类型/常量运算的库，方便开发者。例如Boost.MPL和Boost.PP；
- 增加C++的语言内描述能力，也就是Embedded DSL。例如Spirit和Proto，都是很好的例子；
- 做尽可能多的静态检查。比如Boost.Chrono将单位绑定到类型中，解决了单位转换容易出错的问题。
而STL因为处于标准中，所以会对不同平台的编译器都做出了统一要求，需要编译器配合的地方，也不会用语言机制或者奇技淫巧来迁就，例如Static Assertion、Auto、decltype，在Boost当中是以一定的技巧实现的（因为编译器不能直接支持），而在C++11种就变成了一个内置的语言特性。与此类似的还有很多的Type Traits。
对于User而言，Boost/STL的库可以分为四种风格。
- 第一种风格为Lib风格，以提供功能为主，使用方法一般也就是as-is。例如Pool，Graph，Interval，Chrono，ASIO等。它们的接口使用也可以分为两个部分，第一阶段是型别特化，第二阶段是基于运行时接口。STL和Boost里，大部分库都是这样的风格。这也是最容易使用和使用频率最高的风格。
- 第二种风格是语法糖类。Boost.Foreach等都属于这一类。但是在STL中就非常罕见，因为语言已经得到了充分升级。
- 第三种风格是范式和方法论的拓展，即在C++中模拟其他编程范式和方法论。例如spirit，lambda，proto。严格的说，boost.mpl也可以归属此类。这一类库的使用方式分为两步，第一步是定制方言，第二步是使用方言。这类应用因为面向库的开发者，所以STL中很难见。
- 第四类风格，是元编程。利用模板和宏进行编译器推导，以实现代码展开、选择编译等工作。典型的例子有Boost.PP，STL/Boost.TypeTraits，enable_if等，这一部分对于一般用户是可以不用的。STL中有部分基础的元编程支持（例如Traits）。
因为STL多数是面向一般程序员，所以以第一种库居多，而Boost包含了全部四类的库的风格。
3. 文档
Boost的文档基本上是tutorial风格的，Reference做的并不好。而被标准化的STL通常会有更加清晰易读的Reference。
4. 平台特定性
Boost有很多支持不同平台、或者IO相关的玩意儿，比如Boost.Process，GIL，ASIO，Context，哪个都不是平台无关的省油灯。反观STL对这方面一直都很保守，之前一直就只有容器这类东西，C++11之后才把Thread、File System这种和平台有些关系的内容陆续给弄进来，IO和网络到现在都是一块一毛不拔的荒地。
5. 问题
Boost和STL的问题几乎是相通的，就是因为模板使用多，编译时间较长，二进制也相对较大。编译错误也不是非常明确。Boost中一些元编程分量更多的库，例如MSM和Spirit的问题要更加严重。
此外，因为Boost是试验性质的库，所以接口可能不是非常稳定。而一旦库进入STL之后，就几乎不可能有变化了。比如Boost.Filesystem在进入TR2之前，先后有三个比较大版本的API变动；Spirit也做出了一次比较大的调整。
还有就是，Boost的库和其它语言的标准库相比，零散杂乱，我经常也忘记Boost/STL中的某些库，自己去发明了一个一点都不好用的轮子。
6. 干儿子
最后就是，虽然Boost是标准委员会的干儿子，但是也不保证它的实现就一定是进入STL。比如网络库，最后进标准的，应该是CppNetlib，而不是ASIO。
references：
http://www.zhihu.com/question/27558334
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
