书籍介绍

这本书最独特的地方，在于它不是按概念目录平铺直叙，而是抛出47个真实的工程难题，逼你先把代码写错、把坑踩穿，再回头领悟解法。读者反复提及的

AI导读

核心看点

通过47个工程难题，深入讲解C++异常安全与类设计。
详解Pimpl惯用法，有效降低编译依赖，提升编译速度。
剖析名字查找规则与接口设计，揭示标准库背后的设计思想。

读者共识

异常安全与Copy-Swap惯用法的讲解令人信服且深刻。
关于编译防火墙和Pimpl的优化技巧极具实用价值。
部分面向对象设计内容被认为不够深入，建议多读几遍。

精彩摘录

"If a function isn't going to handle (or translate or deliberately absorb) an exception, it should allow the exception to propagate up to a caller who can handle it."
"Always structure your code so that resources are correctly freed and data is in a consistent state even in the presence of exceptions."
"Observe the canonical exception safety rules: Never allow an exception to escape from a destructor or from an overloaded operator delete() or operator delete[](); write every destructor and deallocation function as though it had an exception specification of "throw()"."
"Observe the canonical exception-safety rules: in each function, take all the code that right emit an exception and do all that work safely off to the side. Only then, when you know that the real work has succeeded, should you modify the program state (and clean up) using only nonthrowing operations."
"Prefer cohesion. Always endeavor to give each piece of code – each module, each class, each function – a single, well-defined responsibility."
"Always use the "resource acquisition is initialization" idiom to isolate resource ownership and management."
"Exception specifications can incur a performance overhead whether an exception is thrown or not, although many compilers are getting better at minimizing this. For widely-used operations and general-purpose containers, it may be better not to use exception specifications in order to avoid this overh"
"All destructors should always be implemented as though they had an exception specification of throw() -- that is, no exception must ever be allowed to propagate."