Effective C++第四篇，扩展的有点多...
(四).设计与声明
____________________________________________________________________________________________________________________________________
条款24：若所有参数皆需类型转换，请为此采用non-member函数
#1.如果你需要为某个函数的所有参数（包括被 this指针所指的那个隐喻参数）进行
类型转换，那么这个函数必须是个 non-member。
//假设有个有理数类:
class Rational{
public:
Rational(int numrator=0, int denomination=1);
int numerator()const;
int denomination()const;
...
};
//如果operator*写成Rational成员函数的话:
class Rational{
public:
...
const Rational operator*(const Rational& rhs)const;
...
};
Rational oneEigth(1,8); //很好
Rational oneHalf(1,2); //很好
Rational result = oneHalf * oneEighth; //很好
result = result * oneEighth //很好
//当尝试混合运算时：
result = oneHalf*2; //result = oneHalf.operator*(2);很好
result = 2*oneHalf; //result = 2.operator*(oneHalf);出错,继续尝试non-member函数
//当编译器试图调用non-member函数 result = operator*(2, oneHalf);时
//依旧没有找到对应的non-member函数，因此最终导致出错。
//【所以我们应该实现一个这样的non-member函数】：
const Rational operator*(const Rational& lhs,const Rational& rhs)
{
return Rational(lhs.numerator()*rhs.numerator(),
lhs.denomination()*rhs.denomination());
}
#2.决定上述non-member函数是non-friend函数还是friend函数的理由是
“是否必须对class内部private成员或protected成员进行访问”，
若需要，则该non-member函数应是friend函数，
若不需要，为满足最大封装性原则，该non-member函数应是non-friend函数。
____________________________________________________________________________________________________________________________________
条款25：考虑写出一个不抛出异常的swap函数
#1.如果swap的缺省实现码对你的class或class template提供了可接受的效率，
请使用该缺省实现版:
namespace std{
template<typename T>
void swap(T&a, T&b) //std:swap的典型实现
{ //置换a和b的值
T temp(a);
a = b;
b = temp;
}
}
反之，如果因class或class template使用了pImp手法(pointer to implementation):
class WidgetImpl{
public:
...
private:
int a, b, c;
std::vector<double> v;
...
};
class Widget{
public:
Widget(const Widget& rhs);
Widget& operator=(const Widget&rhs)
{
...
*pImv = *(rhs.pImpl);
...
}
...
private:
WidgetImpl* pImv;
};
从而引起了效率不足，请做以下几件事来提高效率：
(1).提供一个public swap member函数:
//pImv是private成员变量，所以要从内部来swap,
//当然也可用friend,但这样的写法和STL一致
class Widget{
public:
...
void swap(Widget& other)
{
using std::swap;
swap(pImpl, other.pImpl);
}
...
};
//该swap函数保证了异常安全性和高效性，因为swap置换的是指针，对于指针
//和内置类型的置换操作绝不会抛出异常，并且还很高效。如果是对自定义类型
//执行swap函数，则会因为copy构造函数和copy assignment操作符而允许抛出异常。
(2).在你的class或template所在的namespace(如果没有，则是globe)内提供一个
non-member swap函数,并令它调用上述的swap函数，例如：
namespace WidgetStuff{
...
template<typename T>
class Widget {...}
...
template<typename T>
void swap(Widget<T>& a, Widget<T>& b)
{
a.swap(b);
}
}
(3).如果正在编写的是一个class(而非class template),为你的class特化std::swap，
并让它调用你的swap member函数，例如：
namespace std{
template<>
void swap<Widget>(Widget& a, Widget& b)
{
a.swap(b);
}
}
//=======================================================================
// 理由:
// 好处是即使客户不慎直接调用了std::swap，至少也能获得一个全特化版的swap函数，
// 另外，C++只运行class template偏特化，但不允许function template的偏特化,
// 因此无法通过编译（虽然某些编译器错误的接受了它）。
//=======================================================================
(4).如果你调用swap,请使用using声明式，以便让std::swap在函数中曝光可见，从
而在swap直接书写调用时可获得如下的效率查找：
<1>.在与class相同的 namespace 中查找swap函数。
<2>.在globe坏境中查找swap函数。
<3>.在namesapce std中查找全特化swap函数(如果是class而非template,并且予以了实现）
<4>.在namesapce std中查找一般swap函数。
#2.在std内进行std templates全特化是好的，但千万不要在std内加入一些对于std
来说全新的东西，因为C++标准委员会禁止加入那些已经声明好的东西，即便通过了
编译和执行，其行为也不能得到明确。
____________________________________________________________________________________________________________________________________
（五）.实现
____________________________________________________________________________________________________________________________________
条款26：尽可能延后变量定义式的出现时间
#1.尽可能延后变量定义式的出现，如果可以，要直到初始化为止。
理由1：增加程序的可读性，使程序结构更清晰。
理由2：对于用户(或系统)定义类型，过早的定义变量，可能会导致程序在抛出异常，
函数返回等情况下变量没有使用，因此会带来额外的构造和析构成本。
（内置类型的定义，可以用C风格初始化，也可以延迟变量定义时间，为了统一起见，
最好延迟变量定义的时间。）
例如：
std::string encryptPassword(const std::string& password)
{
using namespace std;
string encrypted;
if(password.length() < MinimumPasswordLength)
throw logic_error("Password is too short");
...
return encrypted;
}
//若抛出logic_error异常，encrypted完全未被使用。
//所以应改为：
std::string encryptPassword(const std::string& password)
{
if(password.length() < MinimumPasswordLength)
throw logic_error("Password is too short");
using namespace std;
string encrypted(password);
...
return encrypted;
}
#2.方法A和方法B的定义方式各有千秋，如果你知道赋值的成本比“构造+析构”的成本低，
并且注重效率，那么你应该使用方法A。否则，为了保证程序的可读性和易维护性，
你应该使用方法B。
//方法A:定义于循环外
Widget w;
for(int i=0;i<n;i++){
w = 取决于i的某个值;
...
}
//方法B:定义于循环外
for(int i=0;i<n;i++){
Widget w(取决于i的某个值);
}
//做法A:1个构造函数+1个析构函数+n个赋值操作
//做法B:n个构造函数+n个析构函数
____________________________________________________________________________________________________________________________________
条款27：尽量少做转型动作
#1.const_cast,dynamic_cast,reinterpret_cast,static_cast转型操作符。
const_cast:常量性转除，唯一有此能力的C++-style转型操作符。
dynamic_cast:主要用来执行”安全向下转型“，也就是用来决定某对象是否归属
于继承体系中的某个类型。它是唯一无法由旧式语句执行的动作，也是唯一可能
耗费重大运行成本的转型动作。
reinterpret_cast:意图执行低级转型，实际动作（及结果）可能取决于编译器，
这也表示它不可移植，例如将一个 pointer to int 转型为一个 int。这一类
转型在低级代码以为很少见。
static_cast:强迫隐式转换，例如
将 non-contst 转型为 const,
将 int 转型为 double,
将 void*指针与 typed指针互转，
将 pointer-to-base 与 pointer-to-derived互转，
但无法将 const 转型为 non-const,因为这个只有const_cast办的到。
#2.如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_cast，如果
有个设计需要转型动作，试着发展无需转型的替代设计。
理由1：C++规则的设计目标之一是，保证“类型错误”绝不发生，为避免在任何对象
身上执行不安全，荒谬的操作，请尽量避免转型。
理由2：任何一个类型转换往往令编译器编译出运行期间执行的码，例如：
class Base{...};
class Derived:public Base{...};
Derived d;
Base* pb = &d;
//为获取Base*指针值，在运行期间会有个偏移量(offset)添加在Derived*指针身上，
//编译器会为此额外编译出运行期间执行的码。（注意：这里的offset并不明确，
//因为对象的布局方式和地址计算方式随编译器的不同而不同。)
理由3：dynamic_cast会耗费重大的运行期成本，在深度继承中，单单多次的
”class名称之字符串“的strcmp比较就会耗费一定的效率成本。
【两种避免dynamic_cast转型的替代策略】：
(1).在单一继承中，直接用 derived class 指针替代 base class 接口处理的derived
class 对象，例如：
//假设先Window/SpecialWindow继承体系中只有SpecialWindows才支持闪烁效果，
//试着不要这样做：
class Window {...};
class SpecialWindow:public Window{
public:
void blink();
...
};
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;
VPW winPtrs;
...
for(VPW::iterator iter = winPtrs.begin();
iter != winPtrs.end();++iter){
if(Specialwindow* psw=dynamic_cast<SpecialWindow*>(iter->get()))
psw->blink();
}
//应该改成这样:
typedef std::vector<std::tr1::shared_ptr<SpecialWindow>> VPW;
VPW winPtrs;
...
for(VPW::iterator iter = winPtrs.begin();
iter != winPtrs.end();++iter){
(*iter)->blink();
}
(2).多重继承中，用virtual函数代替dynamic_cast所做的事
//用dynamic_cast时如下所示：
class Window {...};
...
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;
VPW winPtrs;
...
for(VPW::iterator iter = winPtrs.begin();
iter != winPtrs.end();++iter){
if(SpecialWindow* psw1=
dynamic_cast<SpecialWindow*>(iter->get()))psw1>blink();
else if(SpecialWindow* psw2=
dynamic_cast<SpecialWindow*>(iter->get()))psw2->blink();
else if(SpecialWindow* psw3=
dynamic_cast<SpecialWindow*>(iter->get()))psw3->blink();
}
//以上的做法中有一连串dynamic_cast,这会使产生出来的代码又长又慢，
//而且基础不稳，因为继承体系一有改变，所有这一类代码都要检查看看
//是否需要修改，例如添加一个新的derived class，则要在一连串判断
//中加入新的条件分支，及其不易维护。
//所以应该改成这样：
class Window {
public:
virtual void blink();{} //缺省实现码什么也没做
...
};
class SpecialWindow:public Window{
public:
virtual void blink(){...}; //blink做某些事
...
};
...
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;
VPW winPtrs;
... //容器，内含Window指针，指向所有可能的派生类对象
for(VPW::iterator iter = winPtrs.begin();
iter != winPtrs.end();++iter){
(*iter)->blink();
}
#3.如果转型无可避免，请将它隐藏在函数背后，这样客户调用该函数时，不需要将
转型动作放入它们的代码里，保证了代码的封装性和易维护性。
#4.尽量用C++-style的转型替换旧式转型（构造函数除外），因为
(1).它们很容易在代码中辨别出来，因此简化了“找出类型系统破坏点”的过程。
(2).转型动作分门别类，因此更有利于编译器找出错误的运用。
____________________________________________________________________________________________________________________________________
条款28：若返回 handles 指向对象内部成分，请保证返回值 const 约束大于等于成员函数
#1.References, 指针和迭代器通通都是 handles,用来取得某个对象。
#2.若返回handles指向内部对象，并且成员函数是const,请保证该返回值也是const 。
class Point{
public:
Point(int x, int y);
...
void setX(int newVal);
void setY(int newVal);
...
};
struct RectData{
Point ulhc;
Point lrhc;
};
class Rectangle{
...
private:
std::tr1::shared_ptr<RectData> pData;
Point& upperLeft()const{return pData->ulhc;}
Point& lowerRight()const{return pData->lrhc;}
...
};
Point coord1(0,0);Point coord2(100, 100);
const Rectangle rec(coord1, coord2);
rec.upperLeft().setX(50);
//这里返回的handles可以改变，但与upperLeft const()成员函数的本意是相反的。
//所以应改成：
class Rectangle{
...
private:
...
const Point& upperLeft()const{return pData->ulhc;}
const Point& lowerRight()const{return pData->lrhc;}
...
};
//这样就可以在保证读写权的同时禁止涂写权。
【本条为个人观点：】
#3.对于返回值为自定义(或系统定义）类型的non-const成员函数，返回内部成员
变量的handles(non-const)表示希望该内部变量是public，而对于返回值为内置
类型的成员变量，则该使用pass-by-valued的getXXX()函数和setXXX(X)来分别
区分读写行为。
例如：
//当upperLeft(),lowerRight()为non-const时：
class Rectangle{
...
private:
...
Point& upperLeft(){return pData->ulhc;}
Point& lowerRight(){return pData->lrhc;}
...
};
Point coord1(0,0);Point coord2(100, 100);
Rectangle rec(coord1, coord2);
//我们可以如下这样用函数统一接口设置值和得到值:
rec.upperLeft().setX(50);
int val = rec.lowerRight().getY();
____________________________________________________________________________________________________________________________________
条款29：为”异常安全“而努力是值得的
#1.异常安全函数即使发生异常也不会泄露资源或允许任何数据败坏。
这样的函数区分三种可能的保证：基本型，强烈型，不抛异常性。
(1).基本型：异常抛出后，class一切约束条件满足，程序内事物处于一种有效的状态中。
(2).强烈保证型：异常抛出后，程序状态不改变，函数回到调用前的状态。
(3).不抛异常型：保证不抛出任何异常，对内置类型（int,指针，等）身上的所有操作
都提供nothrow保证。
（任何使用动态内存的东西在无法满足内存需求下，都会抛出bad_alloc异常）
#2.除非调用传统非安全异常安全码，否则应保证异常安全，因为传统非异常安全码
不具备异常安全性，所以任何调用它的代码都不具备异常安全性，因此为其撰写
异常安全码是么有任何意义的。
#3.”强烈保证“往往能够以 copy-and-swap实现出来。
//一个用copy-and-swap的示例：
struct PMImpl{ //PMImpl = PrettyMenu Impl
std::tr1::shared_ptr<Image> bgImage;
int imageChanges;
};
class PrettyMenu{
...
private:
Mutex mutex;
std::tr1::shared_ptr<PMImpl> pIml;
};
void PrettyMenu::changeBack(std::istream& imgSrc)
{
using std::swap;
Lock ml(&mutex); //获得mutex的副本数据
std::tr1::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl));
pNew->bgImage.reset(new Image(imgSrc)); //修改副本
++pNew->ImageChanges;
swap(Impl, pNew); //置换(swap)数据，释放mutex
}
//，但”强烈保证“ 并非对所有函数都具有可实现或具备实现意义:
(1).因为如copy-and-swap这样的强烈保证往往会耗费更多的时间和空间，为了
保证更好的效率，应以”基础保证“来替换，这样才更具现实意义。
(2).当函数对”非局部性数据”有影响时，提供强烈保证就很难了。
void someFunc{
... //对local状态做一份副本
f1();
f2();
... //将修改后的状态置换过来
}
//假设someFunc对“局部数据”提供强烈保证，但f1(),f2()对someFunc()来说是
//非局部性的”，因此f1(),f2()会对someFunc()的强烈保证期望造成影响，
//假设f1(),f2()提供一个基本保证，显然someFunc将只会提供基本保证，
//而若f1(),f2()也提供强烈保证，但若f1(),f2()并未抛出异常，在此之后
//却抛出了异常，那么someFunc()也无法提供强烈保证，毕竟程序状态改变了。
//另一方面，在someFunc中像某些数据库之类的非局部数据一旦被改变，想恢复
//就很困难，这时someFunc想提供强烈保证就真的很难了。
#4.函数提供的“异常安全保证”最多只等于其所调用之各个函数的“异常安全保证”
中的最弱者（从上述例子中可以看出）。
____________________________________________________________________________________________________________________________________