程序库随想

我们总是希望有这样一个库：它能够让我们方便的完成某个任务，如果A库使用起来比B库简单那么一点点，我们就更愿意使用A。因此，我们也经常干这样的事情：把一个现有的库做一个薄封装，从而使用起来更适合当前的编程环境。
一般而言，简单的库总是更好的，然而这并不是一定的。我总是能听到一些程序员抱怨：为什么XX库的YY功能不能预先提供一个最简单的使用方式，非要程序员再手工做一些工作。我想，这有两个解释：1是这种期望的最简形式是非一般性的，是特例，作为库，无法为没有预见到的使用做万全的准备。2.程序库故意这么做，迫使程序员必须要额外做一些事情。
对于第一种情况，程序员可做的就是自己稍加封装。第二种情况，则值得思考。
在一个复杂软件中，当我们引入一个库时，必须小心，要防止库破坏现有的代码。另外，鉴于程序员对库的认识总是会存在局限性，误用就是一个很严重的问题了。一方面，这和程序员素质有关，另一方面，就需要程序库来帮助防御误用和减少隐藏的错误。
我在ACE的使用过程中就遇到这样的问题，有些程序员对TCP的工作机制并不了解，在使用Sock_Stream的时候，当然也遇到了大量的错误－－程序能够工作，却Bug不断。而在使用Boost.Thread以及Boost.Bind库的时候，发生的错误几乎是立刻发现－－要么编译失败，要么一运行立刻报错，因此在提交测试以后，几乎不存在线程方面的Bug,只有个别和Lock有关的错误，遗憾的是查阅文档并不能马上确定这些用法有问题。
我这里不是在诋毁ACE而捧Boost，这是两者的基础知识域的差异导致的。事实上，ACE库使用中遇到的错误也是很容易纠正的。然而反观我们常用的其他一些库，特别是MFC，固然提供了一些封装，但是这些封装却常常误导程序员，把我们引入歧途。MFC倒还不是最恶劣的，最恶劣是某些公司内部的库，过分的追求使用简单，却到处都是危险的陷阱：主线程正常，多线程错误；不可重入；成对操作缺少明显的说明；必须的运行环境不作为约束出现，而是将一个最普遍的环境作为默认；本应该是纯虚函数的，却提供一个缺省实现。如此种种，不一而足。
那么，这些内部的库就没有价值吗？当然不是，价值还是有的，有时候甚至非他不可。但是这些库就像一个过度溺爱孩子的妈妈，用的时候还挺爽，然而爽过之后，大错筑成，往往有种想杀人的冲动！而一个好的库，就像是诤友，他总是在你需要的时候给予恰当的帮助，却又能够阻止你犯下错误。提供程序库的时候，如何阻止用户程序员的错误，也是一个需要考虑的问题。