我一直在浏览Boost库的1.38.0版本，试图判断是否有足够的宝石来证明与公司的外部软件批准流程谈判是值得的。在编写测试程序和阅读文档的过程中，我得出了一些结论：
事实上，对我来说，有些库似乎有点玩具般。
有一些相当易于使用的库，我可以看到只需进行短期调查即可投入使用，例如boost::variant（我真的很喜欢visitor组件以及如果访问者缺少一个变量类型的运算符，编译器会报错的事实）。我会使用boost::shared_ptr，除了我们的小组已经有一套智能指针类型之外。
因此，基于Stack Overflow用户的广泛经验，哪些Boost库
请注意，这与Boost considered harmful?中提出的问题略有不同。
P.S. - 是否已经删除了其中一个答案（来自litb）？我在这里看不到它，只有我的用户页面上的摘录...
我经常使用以下内容（它们让我的生活更简单）：
智能指针（shared_ptr、scoped_ptr、weak_ptr、进程间unique_ptr）：
scoped_ptr用于基本的RAII（不涉及共享所有权和所有权转移），无需代价。shared_ptr用于更复杂的操作——当需要共享所有权时。但是，这会带来一些代价。unique_ptr——在Boost上有积极的工作，将unique_ptr的各种方法（在Boost中存在）与移动仿真统一起来。unique_ptr）Boost Thread - 一个用于处理线程的库，正在积极开发（现在可移动）。它隐藏了在特定平台上实现线程的复杂性。
Boost MPL和Fusion - 这些比较难解释。长时间以来，我没有使用编译时强大功能，但是经过一些阅读和学习，发现我的一些代码可以得到很好的简化。不过，要注意编译时间......
Boost Asio
Boost Format（强大的输出格式化，但非常重）
Boost Spirit2x（Karma和Qi都用于解析和生成基于给定语法的输出）。非常强大，可以创建一个解析器而无需使用外部工具。但是编译时间可能会成为问题。此外，版本2x正在积极开发中，文档相对较少（spirit-devel邮件列表非常有帮助）
Boost Bind、Function和Lambda，让你的生活更轻松，以及Boost Phoenix - 只是用来进行实验
lexical_cast（类似的东西可能很快就会成为boost::string）
正则表达式/ Xpressive - 正则表达式
类型特征和概念检查 - 再次让您的生活更轻松
数学：
Boost迭代器（专门用于迭代器的适配器和外观，可创建自己的迭代器）
Boost单元测试框架
仍然有一些我几乎没有涉及的Boost部分。 可能我也忘记了提到几个明显的部分。
记得用正确的工具（锤子）解决正确的问题（钉子）。 记得保持解决方案简单。 记住接收功能的成本（例如shared_ptr 或boost :: format 运行时开销，MPL / Fusion / Spirit / Phoenix编译时成本和可执行文件大小）。 但是进行实验和学习-这就是乐趣所在。
而且，当涉及说服管理层使用新库时-您不必从所有库开始。 从简单的事情开始（可能是具有悠久而稳定的Boost历史记录，广泛的编译器支持，计划纳入TR2 / C ++ 1x等）以及演示收益的简单示例。
我发现在设计跨平台（如*nix和win32）的多线程应用程序时，boost是一个无可争议的必备品(boost::thread, boost::interprocess)。至少在一个实例中，仅仅这一点就足以证明采用boost作为我们雇主项目的一部分。
其余的内容（容器、通用编程和元编程、内存）都是免费的附赠礼品。
我经常使用boost::filesystem。它可以完成简单文件管理的所有必要操作。
enable_if，type/function_traits）variant、optional - 就像你已经注意到的那样也许还有Python（从未尝试过，但某些如KDE程序使用它）
for_each(a.begin(), a.end(), std::cout << _1 << ' ');
这段代码将所有容器中的元素用空格分隔输出。
我个人认为你应该看一下那些隐藏平台特定内容的库，例如线程，进程间通信，内存映射文件，文件系统，异步IO等。
这些库可以在多平台项目中节省大量时间和麻烦，并且往往专注于暴露功能而不是炫酷的C++特性练习。
如果您需要解析比简单键/值对更复杂的文本文件，我强烈推荐使用Boost::spirit。它的学习曲线很陡峭，但一旦掌握了它，您就可以轻松地将EBNF语法直接嵌入到代码中。它比编写自己的解析器要健壮得多。我还发现自己创建的文件格式更多地是为了方便文件编写者而不是解析代码的编写者。