https://www.douban.com/note/499300037/
最近一年我电话面试了数十位 C++ 应聘者，惯用的暖场问题是“工作中使用过 STL 的哪些组件？使用过 Boost 的哪些组件？”。得到的答案大多集中在 vector、map 和 shared_ptr。如果对方是在校学生，我一般会问问 vector 或 map 的内部实现、各种操作的复杂度以及迭代器失效的可能场景。如果是有经验的程序员，我还会追问 shared_ptr 的线程安全性、循环引用的后果及如何避免、weak_ptr 的作用等。如果这些都回答得不错，进一步还可以问问如何实现线程安全的引用计数，如何定制删除动作等等。这些问题让我能迅速辨别对方的
C++ 水平。
我之所以在面试时问到 Boost，是因为其中的许多组件确实可以用于编写可维护的产品代码。Boost 包含近百个程序库，其中不乏具有工程实用价值的佳品。每个人口味与技术背景不一样，对 Boost 的取舍也不一样。就我的个人经验而言，首先可以使用绝对无害的库，例如 noncopyable、scoped_ptr、static_assert 等，这些库的学习和使用都比较简单，容易入手。其次，有些功能自己实现起来并不困难，正好 Boost 里提供了现成的代码，那就不妨一用，比如date_time 和 circular_buffer 等。然后，在新项目中，对于消息传递和资源管理可以考虑采用更加现代的方式，例如用 function/bind 在某些情况下代替虚函数作为库的回调接口、借助shared_ptr实现线程安全的对象回调等等。这二者会影响整个程序的设计思路与风格，需要通盘考虑，如果正确使用智能指针，在现代 C++ 程序里一般不需要出现 delete 语句。最后，对某些性能不佳的库保持警惕，比如 lexical_cast。总之，在项目组成员人人都能理解并运用的基础上，适当引入现成的 Boost 组件，以减少重复劳动，提高生产力。
Boost 是一个宝库，其中既有可以直接拿来用的代码，也有值得借鉴的设计思路。试举一例：正则表达式库 regex 对线程安全的处理。
早期的 RegEx 类不是线程安全的，它把“正则表达式”和“匹配动作”放到了一个类里边。由于有可变数据，RegEx 的对象不能跨线程使用。如今的 regex 明确地区分了不可变（immutable）与可变（mutable）的数据，前者可以安全地跨线程共享，后者则不行。比如正则表达式本身（basic_regex）与一次匹配的结果（match_results）是不可变的；而匹配动作本身（match_regex）涉及状态更新，是可变的，于是用可重入的函数将其封装起来，不让这些数据泄露给别的线程。正是由于做了这样合理的区分，regex 在正常使用时就不必加锁。
Donald Knuth 在“Coders at Work”一书里表达了这样一个观点：如果程序员的工作就是摆弄参数去调用现成的库，而不知道这些库是如何实现的，那么这份职业就没啥乐趣可言。换句话说，固然我们强调工作中不要重新发明轮子，但是作为一个合格的程序员，应该具备自制轮子的能力。非不能也，是不为也。
C/C++ 语言的一大特点是其标准库可以用语言自身实现。C 标准库的 strlen、strcpy、strcmp 系列函数是教学与练习的好题材，C++ 标准库的 complex、string、vector 则是类、资源管理、模板编程的绝佳示范。在深入了解 STL 的实现之后，运用 STL 自然手到擒来，并能自动避免一些错误和低效的用法。
对于 Boost 也是如此，为了消除使用时的疑虑，为了用得更顺手，有时我们需要适当了解其内部实现，甚至编写简化版用作对比验证。但是由于 Boost 代码用到了日常应用程序开发中不常见的高级语法和技巧，并且为了跨多个平台和编译器而大量使用了预处理宏，阅读 Boost 源码并不轻松惬意，需要下一番功夫。另一方面，如果沉迷于这些有趣的底层细节而忘了原本要解决什么问题，恐怕就舍本逐末了。
Boost 中的很多库是按泛型编程的范式来设计的，对于熟悉面向对象编程的人而言，或许面临一个思路的转变。比如，你得熟悉泛型编程的那套术语，如concept、model、refinement，才容易读懂 Boost.Threads 的文档中关于各种锁的描述。我想，对于熟悉 STL 设计理念的人而言，这不是什么大问题。
在某些领域，Boost 不是唯一的选择，也不一定是最好的选择。比如，要生成公式化的源代码，我会首选用脚本语言写一小段代码生成程序，而不用 Boost.Preprocessor；要在 C++ 程序中嵌入领域特定语言，我会首选用 Lua 或其他语言解释器，而不用 Boost.Proto；要用 C++ 程序解析上下文无关文法，我会首选用 ANTLR 来定义词法与语法规则并生成解析器（parser），而不用 Boost.Spirit。总之，使用 Boost 时心态要平和，别较劲去改造 C++ 语言。把它有助于提高生产力的那部分功能充分发挥出来，让项目从中受益才是关键。
要学习 Boost，除了阅读其官方网站的文档、示例与源码之外，最好能有一本比较全面的中文书在手边随时翻阅。对于不谙英文的开发者，这更是可幸之至。您手上这本《Boost 程序库完全开发指南》是很好的使用指南与参考手册。作者由浅入深地介绍了 Boost 的大部分常用内容，能让读者迅速了解 Boost，并从中找到自己需要的部分。拿到这本书稿之后，我有粗有细地阅读了一遍，总体来看，作者水平很高，也相当务实，对 C++ 和 Boost 的理解与运用很到位，我从这本书学到了不少新知识。为此，我乐于向希望学习 Boost 程序库的开发者推荐这本靠谱的书。
须知“功不唐捐”，作为一名现代 C++ 程序员，在 Boost 上投入的精力定能获得回报。
我之所以在面试时问到 Boost，是因为其中的许多组件确实可以用于编写可维护的产品代码。Boost 包含近百个程序库，其中不乏具有工程实用价值的佳品。每个人口味与技术背景不一样，对 Boost 的取舍也不一样。就我的个人经验而言，首先可以使用绝对无害的库，例如 noncopyable、scoped_ptr、static_assert 等，这些库的学习和使用都比较简单，容易入手。其次，有些功能自己实现起来并不困难，正好 Boost 里提供了现成的代码，那就不妨一用，比如date_time 和 circular_buffer 等。然后，在新项目中，对于消息传递和资源管理可以考虑采用更加现代的方式，例如用 function/bind 在某些情况下代替虚函数作为库的回调接口、借助shared_ptr实现线程安全的对象回调等等。这二者会影响整个程序的设计思路与风格，需要通盘考虑，如果正确使用智能指针，在现代 C++ 程序里一般不需要出现 delete 语句。最后，对某些性能不佳的库保持警惕，比如 lexical_cast。总之，在项目组成员人人都能理解并运用的基础上，适当引入现成的 Boost 组件，以减少重复劳动，提高生产力。
Boost 是一个宝库，其中既有可以直接拿来用的代码，也有值得借鉴的设计思路。试举一例：正则表达式库 regex 对线程安全的处理。
早期的 RegEx 类不是线程安全的，它把“正则表达式”和“匹配动作”放到了一个类里边。由于有可变数据，RegEx 的对象不能跨线程使用。如今的 regex 明确地区分了不可变（immutable）与可变（mutable）的数据，前者可以安全地跨线程共享，后者则不行。比如正则表达式本身（basic_regex）与一次匹配的结果（match_results）是不可变的；而匹配动作本身（match_regex）涉及状态更新，是可变的，于是用可重入的函数将其封装起来，不让这些数据泄露给别的线程。正是由于做了这样合理的区分，regex 在正常使用时就不必加锁。
Donald Knuth 在“Coders at Work”一书里表达了这样一个观点：如果程序员的工作就是摆弄参数去调用现成的库，而不知道这些库是如何实现的，那么这份职业就没啥乐趣可言。换句话说，固然我们强调工作中不要重新发明轮子，但是作为一个合格的程序员，应该具备自制轮子的能力。非不能也，是不为也。
C/C++ 语言的一大特点是其标准库可以用语言自身实现。C 标准库的 strlen、strcpy、strcmp 系列函数是教学与练习的好题材，C++ 标准库的 complex、string、vector 则是类、资源管理、模板编程的绝佳示范。在深入了解 STL 的实现之后，运用 STL 自然手到擒来，并能自动避免一些错误和低效的用法。
对于 Boost 也是如此，为了消除使用时的疑虑，为了用得更顺手，有时我们需要适当了解其内部实现，甚至编写简化版用作对比验证。但是由于 Boost 代码用到了日常应用程序开发中不常见的高级语法和技巧，并且为了跨多个平台和编译器而大量使用了预处理宏，阅读 Boost 源码并不轻松惬意，需要下一番功夫。另一方面，如果沉迷于这些有趣的底层细节而忘了原本要解决什么问题，恐怕就舍本逐末了。
Boost 中的很多库是按泛型编程的范式来设计的，对于熟悉面向对象编程的人而言，或许面临一个思路的转变。比如，你得熟悉泛型编程的那套术语，如concept、model、refinement，才容易读懂 Boost.Threads 的文档中关于各种锁的描述。我想，对于熟悉 STL 设计理念的人而言，这不是什么大问题。
在某些领域，Boost 不是唯一的选择，也不一定是最好的选择。比如，要生成公式化的源代码，我会首选用脚本语言写一小段代码生成程序，而不用 Boost.Preprocessor；要在 C++ 程序中嵌入领域特定语言，我会首选用 Lua 或其他语言解释器，而不用 Boost.Proto；要用 C++ 程序解析上下文无关文法，我会首选用 ANTLR 来定义词法与语法规则并生成解析器（parser），而不用 Boost.Spirit。总之，使用 Boost 时心态要平和，别较劲去改造 C++ 语言。把它有助于提高生产力的那部分功能充分发挥出来，让项目从中受益才是关键。
要学习 Boost，除了阅读其官方网站的文档、示例与源码之外，最好能有一本比较全面的中文书在手边随时翻阅。对于不谙英文的开发者，这更是可幸之至。您手上这本《Boost 程序库完全开发指南》是很好的使用指南与参考手册。作者由浅入深地介绍了 Boost 的大部分常用内容，能让读者迅速了解 Boost，并从中找到自己需要的部分。拿到这本书稿之后，我有粗有细地阅读了一遍，总体来看，作者水平很高，也相当务实，对 C++ 和 Boost 的理解与运用很到位，我从这本书学到了不少新知识。为此，我乐于向希望学习 Boost 程序库的开发者推荐这本靠谱的书。
须知“功不唐捐”，作为一名现代 C++ 程序员，在 Boost 上投入的精力定能获得回报。