海边的贝壳

         此文记录些书中有趣的句子，包括但不仅限于奇妙又别有新意的比喻，恰到好处的幽默，信达雅、兼具两种语言妙处的翻译或是奇奇怪怪的翻译腔。 希望给大家严肃的学习带来一些放松。

---

如果真有错误发生————如果close的确抛出异常————而且DBConn吞下该异常或结束程序，客户没有立场抱怨，毕竟他们曾有机会第一手处理问题，而他们选择了放弃。
                                                                                                   ————effective c++  条款8

---

如果你声明自己的copying函数，意思就是告诉编译器你并不喜欢缺省实现中的某种行为。编译器仿佛被冒犯似的，会以一种奇怪的方式回应：当你的代码几乎必然会出错时却不告诉你。

                                                                                                   ————effective c++ 条款12

---

就像面对众多蹊跷可疑的构造函数一样，我们一改尽可能隔离转型动作，通常是把他隐藏在某个函数内，函数的接口会保护调用者不受函数内部任何肮脏龌龊的动作影响。

                                                                                               —————effective c++ 条款28

---

c++在接口之海上漂浮。

很少有其他性质比得上“一致性”更能导致“接口容易被正确使用”，也很少有其他性质比得上“不一致性”更加剧接口的恶化。

不一致性对开发人员造成的心里和精神上的摩擦和争执，没有任何一个IDE可以完全抹除。

是的，它可以转换为指针，但在此情况下并不够好，因为tr1::share_ptr坚持要以恶不折不扣的指针。

                                                                                                   ————effective c++ 条款18

---

好的types有自然的语法，直观的语义，以及一个或多个高效实现品。

                                                                                               —————effective c++ 条款19

---

一旦程序员领悟了pass-by-value(传值)的效率牵连层面，往往变成十字军战士，一心一意根除pass-by-value带来的种种邪恶。在坚定追求pass-by-reference的纯度中，他们一定会犯下一个致命错误：开始传递一些references指向其实并不存在的对象。这可不是件好事。

一个曾经被当作Rational但如今已经成空，发臭，败坏的残骸，因为它已经被销毁了。任何调用者甚至只是对此函数的返回值做任何一点点运用，都将立刻坠入“无定义行为”的恶地。事实的真相是，任何函数如果返回一个reference指向某个local对象，都将一败涂地。

我不打算再次写出示例来驳斥你这个想法以彰显自己多么厉害，但我可以简单描述为什么你该为了提出这个念头而脸红。

当你必须在“返回一个reference和返回一个object”之间抉择时，你的工作就是跳出行为正确的那个。就让编译器厂商为“尽可能降低成本”鞠躬尽瘁吧，你可以享受你的生活。

                                                                                            ——————effective c++ 条款21

---

如果public接口内的每样东西都是函数，客户就不需要在打算访问class成员时迷惑地试着记住是否使用小括号（圆括号）。他们只要做就是了，因为每样东西都是函数。就生命而言，这至少可以剩下许多骚首弄耳的时间。

见鬼了，你甚至可以实现“惟写访问”，如果你想要的话。

封装的重要性比你最初见到它时还重要。

                                                                                            ——————effective c++ 条款22

---

说到客户时通常我指的是程序员，因为程序员可能被迷惑，被误导，或因糟糕的接口而愤怒，他们所写的代码却不会又这种情绪。 

                                                                                                ——————effective c++ 引言

---

无论何时如果你可以避免friend函数就该避免，因为就像真实世界一样，朋友带来的麻烦往往多过其价值。

                                                                                          ——————effective c++ 条款24

---

但是对于某些类型而言，这些复制动作无一必要；对它们而言swap缺省行为等于时吧高速铁路铺设在慢速小巷弄内。

                                                                                         ——————effective c++  条款25

当强烈保证不切实际时，你就必须提供基本保证。现实中你或许会发现，你可以为某些函数提供强烈保证，但效率和复杂度带来的成本会使它对许多人而言摇摇欲坠。 

                                                                                  ————————effective c++  条款29

除了能够帮助你在鸡尾酒排队上留给大师级程序员一个深刻的印象，一般而言这项性质用途有限。

                                                                                ————————effective c++  条款34

没有人有权利妄称你的class适用于任何人任何事任何物而他们只需花点时间重新定义你的函数就可以享受一切。如果你的不变性凌驾特异性，别害怕说出来。

                                                                                            ————————effective c++  条款35 

有一天我在书店看巴菲特的那本最近很火的自传《滚雪球》，开篇就提到巴菲特小时候第一次滚雪球的场景，“1939年的冬天，9岁的巴菲特在院子里玩雪。他把少量的积雪铲到一起，揉成一个雪球，然后把他放在地上慢慢滚动，雪球越滚越大······从此，巴菲特再也没有停下脚步，目光投向白雪皑皑的整个世界······”（虽然你可以缩这只是一种修辞或衬托，但不可否认的是它背后隐藏的是一种无法抗拒的归因倾向）。这种手法读来令人倍感深沉，仿佛冥冥之中有一条强大而确定的因果之线，穿越60年光阴，将人一生所有的事情穿在一起，令人肃然起敬。然而这并不是事实，从一个单体个体的观察角度来说，外界的不确定性因素实在太多了，机缘巧合的事情太多了。然而无论是作者本人还是客观作家都很难抵抗这种演绎手法的诱惑，可叹的是这已经是我们能够了解他人的经历，拥有“虚幻”的多重经历的唯一途径。观察、阅读，并别忘呆着你的理性区审视，弄清娱乐就是娱乐。

                                                                       ————《暗时间》