0. 问题

1.【boost有没有用】在哪些情形下STL不够用，需要用到boost，否则就要自己造轮子？这样的情形多不多？会boost之后和其他不会boost的程序员相比有哪些优势？
2.【boost能不能用】在使用C++开发项目的公司里boost库普及情况如何？公司一般允许不允许使用boost库？开源项目用boost的多不多？
3.【boost好不好用】使用boost库的程序是否易于调试？boost库效率如何？在多线程等环境下使用是否安全？
4.【boost好不好学】boost库学习难度如何？应该先深入学习C++再学boost还是掌握C++基本语法就学boost？应该学习boost的全部还是一些重要的部分？
5. 【boost发展前景如何】？

1. 太长不读，先说结论

先说结论：至少得先去看看 boost 现有的 171 个库，它们都是什么。
因为，合理问题是：boost 里面的某个库，我要不要用，而不是 boost 我要不要学习。

2. boost.XXX ，XXX都有什么？

是不是应该先注意到一件事： boost 是一个“大杂烩”一样的库。就是说，不存在一个有某特定功能的 boost库，而是存在 171 个库。
这171个库，作者五湖四海，功能五花八门，非要找到171个库全都有的共同点，大概就一个：它们有一个共同的目标:

“兄弟们，C++标准库看起来很弱鸡啊，让我们都来 boost 它吧！说不定哪天就被招安了……”

这和其它我们更常说的某某 C++库，差异是很大的：

比如：Qt ，虽然它也是个大杂库，有线程、有字符串、有时间、有正则，但终归是为构建跨平台的桌面图形用户界面（GUI）。显然，如果你不写桌面应用，就不用去刻意学习Qt。
再如：sogou/workflow，目标与功能都明确而集中：帮你简化并行计算以及为你提供好用的异步网络框架。同样，如果你不需要写网络服务端应用，也不太需要学习它。

除了没有个功能的业务目标之外（“政治”目标有：就是帮C++撑门户），这一大堆库除了来自五湖四海，目标五花八门之外，它们的质量也不一样。

有的是在所要解决的问题的同类库中虽不是首选，但至少是第一梯队的选择，比如异步库 asio，或者那些本该由标准库提供的，字符串常用的算法，还有那些各种优化的数据结构。
有的呢，也就那样。嗯……纯个人观点吧：比如 boost.Log 似乎不如 spdlog 等没进入boost的日志库；boost.JSON 也不如许多没进入boost的 json库，boost.Format 也不如没有进入 boost 的 fmt……
有的是废弃与代替关系（Coroutine和Coroutine2）
有的是功能重叠的竞争关系（比如 variant 和 variant2）
有的是林青霞和张柏芝的关系（比如 lambda 和 lambda2），美人迟暮
…

再来看这171个库的作用。细说太细了，从大类上看，至少有：

数学的
算法的
容器/数据结构的
异步、网络操作的
并发的
并行计算的
操作系统通用功能封装的（比如 DLL，动态库/共享库，内存、进程、协程、纤程）
配置数据、命令行数据
语言语法功能模拟与增强的（比如模拟语言反射，或者没有rang based for 之前的 foreach）
各种努力以实现函数在C++语言成为“first-class”的……
还有某种设计模式的实现的……（比如 Flyweight）
特定数据结果，比如：图（不是图片，是数据结构中的“图”。比如 Graph 和 GraphParallel），
帮助C++程序员通过 metaprogramming 实现头秃（从而获得更多尊重）
真是来帮补 STL的坑的，比如 IOStreams 、Locale 、Nowide
流行什么我补什么的比如 JSON
突然关心起那些因为各原因可能还在用旧版本C++开发人员的，比如：Comapt 、compatibility 、以及 Move ……
对接其它语言的，不过我只知道有对接 Python的，特别好用
已经被招安的： thread，filesystem、时间，随机数、智指、静态断言、unorder、Bind……（还有好多，这些都不要在boost里面学，而是在STL里学）
…

3. 南老师回答

3.1. boost有没有用

在哪些情形下STL不够用，需要用到boost，否则就要自己造轮子？这样的情形多不多？会boost之后和其他不会boost的程序员相比有哪些优势？

答：这个相当多，至少可分两大类：

一、各种数据结构容器（3）、算法(2）、迭代器。数学库(1)、操作系统功能(7)；
二、补STL坑的（14），特别像 String.Algo ，这哪躲得开。
三、各种偏特定业务的功能的库。比如你要在 C++ 程序里跑 Python（强强联合嘛），就用 boost.Python 以及 Parameter Python Bindings 、或者你要计算CRC、或者你需要做基于动态库的插件系统（那就用上 DLL）、或者需要在在图像数据上做常见处理时（比如要把彩色变成灰度），可以考虑 boost.GIL。
四、并发之类，比如需要用一些适合无锁并发的数据结构
六、小工具，比如命令行参数、三态bool、Config（配置，哪个实际业务项目不需要配置）
七、写的程序突然特别依赖于多数语言有，但C++没有的功能，比如反射、系列化
八、显然没有框架你就干不了的：asio (当然，大框架选择不能太无脑，应和boost之外的库做选型对比)
九、提高编程质量的：异常、错误处理，栈跟踪 Stacktract、单元测试 Test……

3.2 boost能不能用

在使用C++开发项目的公司里boost库普及情况如何？公司一般允许不允许使用boost库？开源项目用boost的多不多？

这有点月经贴了，和更古老的“公司让不让用STL”我认为是一个趋势。一刀切不让用的技术主管应该在急剧消亡，大多数都变得更专业了：只要验证工作和选型工作做得足够，又懂得将特定库以某种形式隔离开来，通常都是可以考虑的。当然，和STL相比，显然，“boost 能不能用”这个问题意义不大，更有意义的是，boost.XXXX 库能不能用。

3.3 boost好不好用

使用boost库的程序是否易于调试？boost库效率如何？在多线程等环境下使用是否安全？

有些 boost 库超好用，有些超难用。中间的要靠认真选型，比如 log 库，json 库这种超具体的。

有些功能，它躲不开的实现方式就决定了它超级难以调试。这和它有没有在 boost 下关系不大。

“多线程等环境下使用是否安全” ？和STL一样，底层库如果实现为多线程安全，其实是一件非常傻的事。

3.4 boost好不好学

boost库学习难度如何？应该先深入学习C++再学boost还是掌握C++基本语法就学boost？应该学习boost的全部还是一些重要的部分？

也是和业务紧密相关的。比如，你想学boost.Process，但你对进程，进程间的通信，这些来自OS 概念都不懂，自然就难学。

再或者，你想学 boost.asio。如果你已经基于多种操作系统的 C socket api 直接编写过各种复杂的网络程序，那学习 asio 时，自然地感觉简单些。而你还在发晕 “咦？为什么服务端只需要一个端口……”这类基本概念问题，自然学习 asio 就难了些。

学习次序：当然应该先学扎实了 c++的知识，再学STL，这其中就有从boost中招安过来的东西，最后再去挑着学习 http://boost.XXX或boost.YYY。

举个例子：从 C++ 到 boost.asio 异步网络编程，比如如何一头用 GUI 写一个图形界面的网络聊天客户端，另一头用 boost.asio 写一个网络聊天服务端，整个路程是比较远的，但我的书有安排了合理的学习路线，从纯C++的玩具例程，到真实的网络并发编程，中间还夹着跨平台的图形用户界面编程 ……没有路线怎么高效？

3.5 boost发展前景

不能太神化 boost库，但也完全不用去担心它的前景。boost会一直是C++标准库（长期）无法拥有的，但业务上又太需要的一些功能的试验地。比如，去年还是前年， boost.mysql 也终于来了。

有人可能也注意前面回答中提到的 boost.Coroutine 和 boost.Coroutine2，boost.variant 和 boost.variant2 ，以及 boost.lambda 和 boost.lambda2 的名字。没错，boost似乎只有认真的进入机制而没有严肃的退出机制(但好像文档里有标明 deprecated )。所以从发展前景来看，boost库在一边继续有新的库进入C++标准，但肯定也会更多的现有的一些库，要进入“deprecated”。这当然正是boost作为标准库的“预备库”应有好处：该活的活，该死的死；同时也让用户更放心 boost 的发展。