The contrast in performance between iostreams and stdio is just an example, however, it's not the main point. The main point is that different libraries offering similar functionality often feature different performance trade-offs, so once you've identified the bottlenecks in your software (via profiling — see Item 16), you should see if it's possible to remove those bottlenecks by replacing one library with another. If your program has an I/O bottleneck, for example, you might consider replacing iostreams with stdio, but if it spends a significant portion of its time on dynamic memory allocation and deallocation, you might see if there are alternative implementations of operator
new
and operator
delete
available (see Item 8 and Item E10). Because different libraries embody different design decisions regarding efficiency, extensibility, portability, type safety, and other issues, you can sometimes significantly improve the efficiency of your software by switching to libraries whose designers gave more weight to performance considerations than to other factors.
Item 23: Consider alternative libraries.(More Effective C++)
转载本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。
上一篇:Item 26: Limiting the number of objects of a class.(More Effective C++)
下一篇:Item 25: Virtualizing constructors and non-member functions.(More Effective C++)
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
《More Effective C++ 》笔记
条款10 防止构造函数里的资源泄露条款20 协助编译器实现返回值优化条款22 考虑使用op=来取代单独的op运算符条款26 限制类对象的个数条款27 要求或禁止对象分配在堆上
构造函数 类对象 编译器 运算符 javascript