编程交流与学习--More Effective C++的学习-Item M23：考虑变更程序库

程序库的设计就是一个折衷的过程。理想的程序库应该是短小的、快速的、强大的、灵活的、可扩展的、直观的、普遍适用的、具有良好的支持、没有使用约束、没有错误的。这也是不存在的。为尺寸和速度而进行优化的程序库一般不能被移植。具有大量功能的的程序库不会具有直观性。没有错误的程序库在使用范围上会有限制。真实的世界里，你不能拥有每一件东西，总得有付出。

    不同的设计者给这些条件赋予了不同的优先级。他们从而在设计中牺牲了不同的东西。因此一般两个提供相同功能的程序库却有着完全不同的性能特征。

    例如，考虑iostream和stdio程序库，对于C++程序员来说两者都是可以使用的。iostream程序库与C中的stdio相比有几个优点（参见Effective C++）。例如它是类型安全的（type-safe），它是可扩展的。然而在效率方面，iostream程序库总是不如stdio，因为stdio产生的执行文件与iostream产生的执行文件相比尺寸小而且执行速度快。

    我做了几种计算机、操作系统和编译器的不同组合，在其上运行程序，在每一种情况下都是使用stdio的程序运行得较快。优势它仅仅快一些（大约20％），有时则快很多（接近200％），但是我从来没有遇到过一种iostream的实现和与其相对应的stdio的实现运行速度一样快。另外，使用stdio的程序的尺寸比与相应的使用iostream的程序要小（有时是小得多）。（对于程序现实中的尺寸，这点差异就微不足道了）。

    应该注意到stdio的高效性主要是由其代码实现决定的，所以我已经测试过的系统其将来的实现或者我没有测试过的系统的当前实现都可能表现出iostream和stdio并没有显著的差异。事实上，有理由相信会发现一种iostream的代码实现比stdio要快，因为iostream在编译时确定它们操作数的类型，而stdio的函数则是在运行时去解析格式字符串（format string）。iostream和stdio之间性能的对比不过是一个例子，这并不重要，重要的是具有相同功能的不同的程序库在性能上采取不同的权衡措施，所以一旦你找到软件的瓶颈（通过进行profile 参见条款M16），你应该知道是否可能通过替换程序库来消除瓶颈。比如如果你的程序有I/O瓶颈，你可以考虑用stdio替代iostream，如果程序在动态分配和释放内存上使用了大量时间，你可以想想是否有其他的operator new 和 operator delete的实现可用（参见条款M8和Effective C++条款10）。因为不同的程序库在效率、可扩展性、移植性、类型安全和其他一些领域上蕴含着不同的设计理念，通过变换使用给予性能更多考虑的程序库，你有时可以大幅度地提高软件的效率。