//---------------------------15/04/09----------------------------
//#26 尽可能延后变量定义式的出现时间
{
/* 1:只要你定义了一个变量而其类型带有一个构造函数或析构函数，即使变量没有被使用
还是要承担构造或析构的成本。为了避免这种情况，应该尽可能延后变量定义式的出现
2:再一次重复条款4：直接给定一个初值来让对象初始化比先构造一个对象，再赋值效率要高。
3:对于循环的情况：
1>当赋值成本低于一组构造＋析构成本时，可以把对象定义在循环外面。
2>反之，把对象定义在循环体内部。
3>效率相当时，应该把对象定义在循环体内部。
*/
}
//#27 尽量少做转型动作
{
/* 1:尽量使用C++的新式转型：
1>const_cast:
通常被用来讲对象的常量性去掉，它是唯一有此功能的转型操作符。
2>dynamic_cast:
执行安全向下转型，但是要耗费大量成本。
3>reinterpret_cast
参数必须是指针，只是转化类型，并不转化内部结构。
想比较于static_cast，static_cast在基类到子类转型时会计算偏移值，而
reinterpret_cast不会，所以这个转型很危险，尽量别用。
4>static_cast
除了去除const属性外，其他转型都行。
2:在类中不要对*this进行转型 */
class Window
{
public:
virtual void onResize(){...}
...
};
class SpecialWindow:public Window
{
virtual void onResize()
{
static_cast<Window>(*this).onResize();
}
};
/* 上面这样调用的是
转型时产生的副本(一个derived临时对象)的 base部分的那个函数。
所以不应该这么调用，而是使用Window::onResize();
3:dynamic_cast转型太慢了，能不用就不用，可以用两个方法避免这个转型：
1>直接使用derived类型的指针
2>在基类中定义一个无操作的virtual函数。
*/
}
//#28 避免返回handles指向对象内部成分
{
/* 1:如果返回一个handles(包括指针，引用，迭代器)指向对象内的private成员变量，那么外部就可以直接
修改这个成员变量了。虽然编译没错，但是这样就没有封装性可言了。
2:这带给我们两个教训：
1>成员变量的封装性最多只等于“返回其handles”的函数的访问级别。如果这个函数是public的
那么这个成员变量就是public的。
2>如果const成员函数传出一个handle，handle所指的数据与对象自身有关"private"或"protected"
而handle又被存储在对象之外，那么这个函数的调用者可以修改上面所指的数据。这是不合理的！！！
3:解决办法：
使返回指针和引用都是const就行了。
引用方式： */
const Point& upperLeft()
const { return pData->ulhc;}
// 指针方式：
const Point * upperLeft()
const { return pData;}
/* 4:返回一个handle代表对象内部成分
总是危险的，这是因为：
handle被传出去就有可能产生 handle比它所指对象生命周期更长。
也就是handle很有可能在某时刻指向不存在的资源: */
GUIObject* pgo;
...
const Point* pUpperLeft = &(boundingBox(*pgo).upperLeft());
// 这里只产生了一个临时对象，所以这条语句结束后就销毁了，而pUpperLeft也指向了已经销毁的对象资源
// 所以能避免返回handlers就避免吧。
}
//#29 为“异常安全”而努力是值得的
{
/* 1:“异常安全”有两个条件：
1>不泄漏任何资源。
解决办法是使用#13的办法，用对象(智能指针)来管理资源。
2>不允许数据败坏
2:异常安全函数提供三种保证之一：
1>基本承诺：如果异常被抛出，程序内的任何事物扔然保持在有效状态下。没有任何对象或数据结构会
因此而败坏，所有对象都处于一种内部前后一致的状态。然而程序的现实状态不可预料。
2>强烈保证：如果异常被抛出，程序状态不改变。调用这样的函数可以有这样的认知：如果函数成功，
就是完全成功，如果函数失败，程序会回到“调用函数前的状态”。
3>不抛掷(nothrow)保证：承诺绝不抛出异常。
3:我们的抉择：
1>有可能的话，提供nothrow保证。
大部分情况：
2>尽可能提供强烈保证，这里有一个好策略，不要为了表示某件事将要发生而改变对象状态，除非那件
事情已经发生了。
有一个好的策略会导致强烈保证：copy and swap。要做的事情就是：
1)先为要打算修改的对象copy一个副本。
2)把要做的事情都在副本上完成。
3)交换原对象和副本。
这里swap函数必须要能保证不抛出异常。
这个策略并不能保证整个函数有强烈的异常安全性。因为：
1)除了copy and swap外，如果还调用了其他函数，那么除非其他函数提供强烈异常保证
以上保证，不然就很难让整个函数提高强烈异常保证了。
2)即使其他函数提供了强烈异常保证，情况还是没有好转，因为其中一个函数改变了程序状态后
另外一个函数抛出了异常。
还有一件事会妨碍你提供强烈异常保证--效率问题，copy and swap带来的是一个对象的复制，
有时会消耗你无法承受的时间和空间。
3>当提供强烈保证不切实际时，就必须提供
基本保证。
但是有时候可能你连基本保证都无法提供，是的。
如果你调用的函数原本不提供保证，那～～除非不调用，不然就没有任何保证了。。。。。
为了别人不会遇到同样的痛苦，你必须尽可能为你的函数提供异常保证。
*/
}