对boundingBox的调用返回的是一个临时对象，这个对象没有名称，随后我们调用了这个对象的upperLeft，返回了一个指向临时对象内部数据的reference。但是在语句结束后，这个临时对象会被销毁，pUpperLeft会变成空悬的、虚吊的(dangling)！
请记住
避免返回handles（包括reference、指针、迭代器）指向对象内部。遵守这个条款可以增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”的可能性降至最低。
条款29：为“异常安全”而努力是值得的
异常安全函数即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。
强烈保证往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可以实现或具备现实意义。
函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中最弱者。
条款30：透彻了解inlining的里里外外
关于inline:
1. inline函数的调用，是对函数本体的调用，是函数的展开，使用不当会造成代码膨胀。
2. 大多数C++的inline函数都放在头文件，inlining发生在编译期。
3. inline函数只代表“函数本体”，并没有“函数实质”，是没有函数地址的。
值得注意的是：
1. 构造函数与析构函数往往不适合inline。因为这两个函数都包含了很多隐式的调用，而这些调用付出的代价是值得考虑的。可能会有代码膨胀的情况。
2. inline函数无法随着程序库升级而升级。因为大多数都发生在编译期，升级意味着重新编译。
3. 大部分调试器是不能在inline函数设断点的。因为inline函数没有地址。
请记住
1. 大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可以使潜在的代码膨胀问题最小化，使程序的速度提升机会最大化。
2. 另外，对function templates的inline也要慎重，保证其所有实现的函数都应该inlined后再加inline。
条款31：将文件间的编译依存关系降至最低
这个问题产生是源于希望编译时影响的范围尽量小，编译效率更高，维护成本更低，这一需求。
实现这个目标首先第一个想到的就是，声明与定义的分离，用户的使用只依赖声明，而不依赖定义（也就是具体实现）。
但C++的Class的定义式却不仅仅只有接口，还有实现细目（这里指实现接口需要的私有成员）。而有时候我们需要修改的通常是接口的实现方法，而这一修改可能需要添加私有变量，但这个私有变量对用户是不应该可见的。但这一修改却放在了定义式的头文件中，从而造成了，使用这一头文件的所有代码的重新编译。
于是就有了pimpl（pointer to implementation）的方法。用pimpl把实现细节隐藏起来，在头文件中只需要一个声明就可以，而这个poniter则作为private成员变量供调用。
这里会有个有意思的地方，为什么用的是指针，而不是具体对象呢？这就要问编译器了，因为编译器在定义变量时是需要预先知道变量的空间大小的，而如果只给一个声明而没有定义的话是不知道大小的，而指针的大小是固定的，所以可以定义指针（即使只提供了一个声明）。
这样把实现细节隐藏了，那么实现方法的改变就不会引起别的部分代码的重新编译了。而且头文件中只提供了impl类的声明，而基本的实现都不会让用户看见，也增加了封装性。
结构应该如下：
class AImpl; class A { public: ... private: std::tr1::shared_ptr<AImpl> pImpl; };
这一种类也叫handle class
另一种实现方法就是用带factory函数的interface class。就是把接口都写成纯虚的，实现都在子类中，通过factory函数或者是virtual构造函数来产生实例。
声明文件时这么写:
class Person { public: static shared_ptr<Person> create(const string&, const Data&, const Adress&); };
定义实现的文件这么写
class RealPerson :public Person { public: RealPerson(...); virtual ~RealPerson(){} //... private: // ... };
以上说的为了去耦合而使用的方法不可避免地会带上一些性能上的牺牲，但作者建议是发展过程中使用以上方法，当以上方法在速度与/或大小上的影响比耦合更大时，再写成具体对象来替换以上方法。
请记住：
支持“编译依存性最小化”的一般构想是：相依于声明式，不要相信于定义式。基于此构想的两个手段是Handles classes和Interface classes。
程序库头文件应该以“完全且仅有声明式”的形式存在，这种做法不论是否涉及templates都适用。
