Effective C++:5、实现

简介:

大多数情况下,适当提出你的 classes(和 class templates)定义以及 functions(和 function templates)声明,是花费最多心力的两件事。一旦正确完成它们,相应的实现大多直截了当。尽管如此,还是有些东西需要小心。太快定义变量可能造成效率上的延迟;过度使用转型(casts)可能导致代码变慢又难维护,又招来微妙难解的错误;返回对象 “内部数据之号码牌(handles)” 可能会破坏封装并留给客户虚吊号码牌(dangling handles);未考虑异常带来的冲击则可能导致资源泄露和数据破坏;过度热心地 inlining 可能引起代码膨胀;过度耦合(couping)则可能导致让人不满意的冗长建置时间(build times)。


所有这些问题都可避免。本章足以解释各种做法。



条款26:尽可能延后变量定义式的出现时间

  • 尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。


条款27:尽量少做转型动作

  • 如果可以,尽量避免转型,特别是在注重效率的代码中避免 dynamic_casts 。如果有个设计需要转型动作,试着发展无需转型的替代设计。

  • 如果转型是必要的,试着将它隐藏于某个函数背后。客户随后可以调用该函数,而不需要将转型放进他们自己的代码内。

  • 宁可使用 C+±style(新式)转型,也要使用旧式转型。前者很容易辨识出来,而且也有着分门别类的职掌。



条款28:避免返回 handles 指向对象的内部成分

  • 避免返回 handles (包括 reference、指针、迭代器)指向对象内部。遵守这个条款可增加封装性,帮助 const 成员函数行为像个 const,并将发生 “虚吊号码牌” (dangling handles)的可能性降至最低。


条款29:为 “异常安全” 而努力是值得的

  • 异常安全函数(Exception-safe functions)即使发生异常也不会泄露资源或允许任何数据结构破坏。这样的函数区分为三种可能的保证:基本型、强烈型、不抛异常。

  • “强烈保证” 往往能够以 copy-and-swap 实现出来,但 “强烈保证” 并非对所有函数都可实现或具备现实意义。

  • 函数提供的 “异常安全保证” 通常最高只等于其调用之各个函数的 “异常安全保证” 中的最弱者。



条款30:透彻了解 inlining 的里里外外

  • 将大多数 inlining 限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级(binary upgradability)更容易,也可使潜在的代码膨胀问题最小化,使程序的速度提升机会最大化。

  • 不要只因为 function templates 出现在头文件,就将它们声明为 inline 。



条款31:将文件间的编译依存关系降至最低

  • 支持 “编译依存性最小化” 的一般构想是:相依于声明式,不要相依于定义式。基于此构想的两个手段是 Handle classes 和 Interface classes 。

  • 程序库头文件应该以 “完全且仅有声明式”(full and declaration-only forms)的形式存在。这种做法不论是否涉及 templetes 都适用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值