C++良好代码风格之我见 - 兼谈boost的工程实用价值

TopLanguage上，一个关于“boost的理念和工程实用价值”的讨论（http://groups.google.com/group/pongba/browse_thread/thread/7501f6ff39b7ff0）吸引了很多人。我这里谈谈我的看法。

 

无疑，boost是很优秀的库（确切的说，是库的集合）。但是我在介绍我的StdExt库的来由时，曾经毫不客气的说，boost 走错了方向。这其中的原因，归结于我对什么才是C++良好代码风格的看法。

 

其一，简单是美。如果一件事情可以用简单的方法去完成，就不要仅仅为了方便花十分的力气去制造语法糖。boost中属于这方面的例子很多，如：boost::lambda, boost::shared_ptr, BOOST_FOREACH等。对于boost::lambda，BOOST_FOREACH，我倾向于在语言层面去引入相关的机制。在没有语言的机制下，多写几行代码完全不是什么难事（boost::lambda完全可以写一个仿函数类来搞定，而且调试方便，用lambda虽然代码少，但是失去了调试的便捷，其实是得不偿失；BOOST_FOREACH则完全可以用标准的for(it = cont.begin(); it != cont.end(); ++it) 搞定）。至于boost::shared_ptr算不算是一种语法糖，还是一种有效的内存管理机制，争议比较大。我从来不认为智能指针可以解决内存泄漏问题（在一个相对简单、封闭的工程环境里使用确实有效，但是并不能适应更复杂的环境），事实上除了COM中我会使用智能指针，其他情况下绝少用。

 

当然，语法糖有时候可能是唯一选择，例如boost spirit、boost xpressive。这两个库目的类似，都是实现一个静态正则文法（第3个类似的库，是我写的TPL）。语法糖在描述正则文法时显得优雅。又如，假设我们要实现一个矩阵（matrix）运算库，虽然add函数也可以做加法，但是用operator+来做矩阵加法显然看起来要优雅许多。

 

其二，项目应形成功能闭包。任何一个项目，都应该有一个明确的目标和问题域。由此而延伸，项目的功能集合应该有个界限，而不是不断膨胀下去。从boost一个个子库看，没有问题。但是从boost这个总体来看，非常有问题，因为它只是一个无主题的大杂烩。没有做物理的子库划分和目标限定，这是我认为boost最为失败的一点。

 

其三，最小外部依赖原则。在我们实现一个项目时，需要谨慎评估我们将依赖哪些外部库，并尽可能将这种依赖最小化。如果我们需要的组件和某个库有非常高的重叠度时，我们说，我们需要这个库；而相反，如果我们只是需要某个库中的一个辅助类时，我们不妨拿来主义，将该类的实现迁移到本项目，而不是不假思索地引用这个库。

 

最小外部依赖原则不单单适用于项目，也适用于单个源代码文件（cpp）的实现。事实上，一个cpp会包含哪些头文件，这些头文件是否真的是这个cpp的正常依赖，同样需要谨慎对待。也许没有工程依赖那么严重，但是这方面的认真考虑将提升你的设计水平。

 

最小外部依赖原则，是导致boost不敢被广泛采纳和使用的重要原因。还是因为boost是个大杂烩，没有进行子库划分和目标限定，这让希望用boost的人无可适从，不能很清晰地评估boost是否适合自己的项目。