C++ code review中的检查项（1）

        最近在做code review，发现在代码写完后按照C++规范作几次review会减少许多调试和后续工作的负担。在这分享一下，也想让自己印象更加深刻。

一。访问和继承方面：

1。使用公有继承体现 "是一个"(IS A) 的含义。不要使用其他方式的继承。

2。严禁public接口出现数据成员,通过get/set接口向外界提供接口。

二。Overridden方面：

1。禁止重新定义继承而来的非虚函数

example:

假设类D公有继承于类B，并且类B中定义了一个公有成员函数mf。mf的参数和返回类型不重要，所以假设都为void。换句话说，我这么写：

class B {
public:
  void mf();
  ...
};

class D: public B {
public:
  void mf();                  // 隐藏了B::mf;

  ...

};

甚至对B，D或mf一无所知，也可以定义一个类型D的对象x，

D x;                          // x是类型D的一个对象

那么，如果发现这么做：

B *pB = &x;                   // 得到x的指针

pB->mf();                     // 通过指针调用B::mf

和下面这么做的执行行为不一样：

D *pD = &x;                   // 得到x的指针

pD->mf();                     // 通过指针调用D::mf

行为的两面性产生的原因在于，象B::mf和D::mf这样的非虚函数是静态绑定的。这意味着，因为pB被声明为指向B的指针类型，通过pB调用非虚函数时将总是调用那些定义在类B中的函数 ---- 即使pB指向的是从B派生的类的对象。

2。禁止重新定义继承而来的缺省参数值

example:

让我们从一开始就把问题简化。缺省参数只能作为函数的一部分而存在；另外，只有两种函数可以继承：虚函数和非虚函数。因此，重定义缺省参数值的唯一方法是重定义一个继承而来的函数。然而，重定义继承而来的非虚函数是一种错误，所以，我们完全可以把讨论的范围缩小为 "继承一个有缺省参数值的虚函数" 的情况。

既然如此，本条款的理由就变得非常明显：虚函数是动态绑定而缺省参数值是静态绑定的。

// 一个表示几何形状的类
class Shape {
public:
  // 所有的形状都要提供一个函数绘制它们本身
  virtual void draw(ShapeColor color = RED) const = 0;

  ...

};

class Rectangle: public Shape {
public:
  // 注意：定义了不同的缺省参数值 ---- 不好!
  virtual void draw(ShapeColor color = GREEN) const;

  ...

};

class Circle: public Shape {
public:
  virtual void draw(ShapeColor color) const;

  ...

};

用图形来表示是下面这样：

                  Shape
                    //
                   /  /
                  /    /
          Rectangle    Circle
         
         
Shape *ps;                      // 静态类型 = Shape*

Shape *pc = new Circle;         // 静态类型 = Shape*

Shape *pr = new Rectangle;      // 静态类型 = Shape*

虚函数是动态绑定的，但缺省参数是静态绑定的。这意味着你最终可能调用的是一个定义在派生类，但使用了基类中的缺省参数值的虚函数：

pr->draw();          // 调用Rectangle::draw(RED)!,而不是Rectangle::draw(GREEN)

这种情况下，pr的动态类型是Rectangle*，所以Rectangle的虚函数被调用 ---- 正如我们所期望的那样。Rectangle::draw中，缺省参数值是GREEN。但是，由于pr的静态类型是Shape*，这个函数调用的参数值是从Shape类中取得的，而不是Rectangle类！所以结果将十分奇怪并且出人意料，因为这个调用包含了Shape和Rectangle类中Draw的声明的组合。你当然不希望自己的软件以这种方式运行啦；至少，用户不希望这样。

三。类型转换方面：

1。避免 "向下转换" 继承层次。如果要进行向下转换的话,使用C++风格的类型转换,采用static_cast,const_cast, dynamic_cast, 和reinterpret_cast4个关键字

example:

C++通过引进四个新的类型转换操作符克服了C风格类型转换的缺点，这四个操作符是, static_cast,const_cast, dynamic_cast, 和reinterpret_cast。在大多数情况下，对于这些操作符你只需要知道原来你习惯于这样写，(type)expression而现在你总应该这样写：

　　static_cast(expression)

　　例如，假设你想把一个int转换成double，以便让包含int类型变量的表达式产生出浮点数值的结果。如果用C风格的类型转换，你能这样写：

　　int firstNumber, secondNumber;
　　...
　　double result = ((double)firstNumber)/secondNumber；

　　如果用上述新的类型转换方法，你应该这样写：

　　double result = static_cast(firstNumber)/secondNumber;

　　这样的类型转换不论是对人工还是对程序都很容易识别。

　　static_cast 在功能上基本上与C风格的类型转换一样强大，含义也一样。它也有功能上限制。例如，你不能用static_cast象用C风格的类型转换一样把struct转换成int类型或者把double类型转换成指针类型，另外，static_cast不能从表达式中去除const属性，因为另一个新的类型转换操作符const_cast有这样的功能。

　　其它新的C++类型转换操作符被用在需要更多限制的地方。const_cast 用于类型转换掉表达式的const或volatileness属性。通过使用const_cast，你向人们和编译器强调你通过类型转换想做的只是改变一些东西的constness或者 volatileness属性。这个含义被编译器所约束。如果你试图使用const_cast来完成修改constness 或者volatileness属性之外的事情，你的类型转换将被拒绝。下面是一些例子：

　　class Widget { ... };
　　class SpecialWidget: public Widget { ... };
　　void update(SpecialWidget *psw);
　　SpecialWidget sw; // sw 是一个非const 对象
　　const SpecialWidget& csw = sw; // csw 是sw的一个引用
　　                           // 它是一个const 对象

　　update(&csw); // 错误!不能传递一个const SpecialWidget* 变量
            　　// 给一个处理SpecialWidget*类型变量的函数

　　update(const_cast(&csw));
　　　　　// 正确，csw的const被显示地转换掉（
　　　　 // csw和sw两个变量值在update
　　　　// 函数中能被更新）

　　update((SpecialWidget*)&csw);
      　　// 同上，但用了一个更难识别
    　　// 的C风格的类型转换

　　Widget *pw = new SpecialWidget;

　　update(pw); // 错误！pw的类型是Widget*，但是
          　　// update函数处理的是SpecialWidget*类型

　　update(const_cast(pw));
　　     // 错误！const_cast仅能被用在影响
    　　// constness or volatileness的地方上。
   　　// 不能用在向继承子类进行类型转换。

　　到目前为止，const_cast最普通的用途就是转换掉对象的const属性。

　　第二种特殊的类型转换符是dynamic_cast，它被用于安全地沿着类的继承关系向下进行类型转换。这就是说，你能用dynamic_cast把指向基类的指针或引用转换成指向其派生类或其兄弟类的指针或引用，而且你能知道转换是否成功。失败的转换将返回空指针（当对指针进行类型转换时）或者抛出异常（当对引用进行类型转换时）：

　　Widget *pw;
　　...
　　update(dynamic_cast(pw));
    　　// 正确，传递给update函数一个指针
  　　// 是指向变量类型为SpecialWidget的pw的指针
　 　// 如果pw确实指向一个对象,
　　// 否则传递过去的将使空指针。
　　void updateViaRef(SpecialWidget& rsw);
　　updateViaRef(dynamic_cast(*pw));
　　   //正确。 传递给updateViaRef函数
  　　// SpecialWidget pw 指针，如果pw
 　　// 确实指向了某个对象
　　// 否则将抛出异常

　　dynamic_casts在帮助你浏览继承层次上是有限制的。它不能被用于缺乏虚函数的类型上（参见条款24），也不能用它来转换掉constness:

　　int firstNumber, secondNumber;
　　...
　　double result = dynamic_cast(firstNumber)/secondNumber;
   　　// 错误！没有继承关系
　　const SpecialWidget sw;
　　...
　　update(dynamic_cast(&sw));
　　  // 错误! dynamic_cast不能转换
 　　// 掉const

　　如你想在没有继承关系的类型中进行转换，你可能想到static_cast。如果是为了去除const，你总得用const_cast。

　　这四个类型转换符中的最后一个是reinterpret_cast。这个操作符被用于的类型转换的转换结果几乎都是实现时定义（implementation-defined）。因此，使用reinterpret_casts的代码很难移植。

　　reinterpret_casts的最普通的用途就是在函数指针类型之间进行转换。例如，假设你有一个函数指针数组：

　　typedef void (*FuncPtr)(); // FuncPtr is 一个指向函数
　　                       // 的指针，该函数没有参数
　　                      // 也返回值类型为void
　　FuncPtr funcPtrArray[10]; // funcPtrArray 是一个能容纳
　　                      // 10个FuncPtrs指针的数组

　　让我们假设你希望（因为某些莫名其妙的原因）把一个指向下面函数的指针存入funcPtrArray数组：

　　int doSomething();

　　你不能不经过类型转换而直接去做，因为doSomething函数对于funcPtrArray数组来说有一个错误的类型。在FuncPtrArray数组里的函数返回值是void类型，而doSomething函数返回值是int类型。

　　funcPtrArray[0] = &doSomething; // 错误！类型不匹配

　　reinterpret_cast

　　可以让你迫使编译器以你的方法去看待它们：

　　funcPtrArray[0] = // this compiles
　　reinterpret_cast(&doSomething);

　　转换函数指针的代码是不可移植的（C++不保证所有的函数指针都被用一样的方法表示），在一些情况下这样的转换会产生不正确的结果（参见条款31），所以你应该避免转换函数指针类型，除非你处于着背水一战和尖刀架喉的危急时刻。一把锋利的刀。一把非常锋利的刀。

　　如果你使用的编译器缺乏对新的类型转换方式的支持，你可以用传统的类型转换方法代替static_cast, const_cast, and reinterpret_cast。也可以用下面的宏替换来模拟新的类型转换语法：

　　#define static_cast(TYPE,EXPR) ((TYPE)(EXPR))
　　#define const_cast(TYPE,EXPR) ((TYPE)(EXPR))
　　#define reinterpret_cast(TYPE,EXPR) ((TYPE)(EXPR))

　　你可以象这样使用使用：

　　double result = static_cast(double, firstNumber)/secondNumber;
　　update(const_cast(SpecialWidget*, &sw));
　　funcPtrArray[0] = reinterpret_cast(FuncPtr, &doSomething);

　　这些模拟不会象真实的操作符一样安全，但是当你的编译器可以支持新的的类型转换时它们可以简化你把代码升级的过程。

　　没有一个容易的方法来模拟dynamic_cast的操作，但是很多函数库提供了函数，安全地在派生类与基类之间的进行类型转换。如果你没有这些函数而你有必须进行这样的类型转换，你也可以回到C风格的类型转换方法上，但是这样的话你将不能获知类型转换是否失败。当然，你也可以定义一个宏来模拟dynamic_cast的功能，就象模拟其它的类型转换一样：

　　#define dynamic_cast(TYPE,EXPR) (TYPE)(EXPR)

　　请记住，这个模拟并不能完全实现dynamic_cast的功能，它没有办法知道转换是否失败。

　　我知道，是的，我知道，新的类型转换操作符不是很美观而且用键盘键入也很麻烦。如果你发现它们看上去实在令人讨厌，C风格的类型转换还可以继续使用并且合法。然而正是因为新的类型转换符缺乏美感才能使它弥补了在含义精确性和可辨认性上的缺点，并且使用新类型转换符的程序更容易被解析（不论是对人工还是对于工具程序），它们允许编译器检测出原来不能发现的错误。这些都是放弃C风格类型转换方法的强有力的理由，还有第三个理由：也许让类型转换符不美观和键入麻烦是一件好事。