2010年4月

(转)static_cast、dynamic_cast、reinterpret_cast和const_cast的区别

关于强制类型转换的问题,很多书都讨论过,写的最详细的是C++ 之父的《C++ 的设计和演化》。最好的解决方法就是不要使用C风格的强制类型转换,而是使用标准C++的类型转换符:static_cast, dynamic_cast。标准C++中有四个类型转换符:static_cast、dynamic_cast、reinterpret_cast、和const_cast。下面对它们一一进行介绍。

static_cast

用法:static_cast < type-id > ( expression_r_r )

该运算符把expression_r_r转换为type-id类型,但没有运行时类型检查来保证转换的安全性。它主要有如下几种用法:
用于类层次结构中基类和子类之间指针或引用的转换。进行上行转换(把子类的指针或引用转换成基类表示)是安全的;进行下行转换(把基类指针或引用转换成子类表示)时,由于没有动态类型检查,所以是不安全的。
用于基本数据类型之间的转换,如把int转换成char,把int转换成enum。这种转换的安全性也要开发人员来保证。
把空指针转换成目标类型的空指针。
把任何类型的表达式转换成void类型。
注意:static_cast不能转换掉expression_r_r的const、volitale、或者__unaligned属性。

dynamic_cast

用法:dynamic_cast < type-id > ( expression_r_r )

该运算符把expression_r_r转换成type-id类型的对象。Type-id必须是类的指针、类的引用或者void *;如果type-id是类指针类型,那么expression_r_r也必须是一个指针,如果type-id是一个引用,那么expression_r_r也必须是一个引用。

dynamic_cast主要用于类层次间的上行转换和下行转换,还可以用于类之间的交叉转换。

在类层次间进行上行转换时,dynamic_cast和static_cast的效果是一样的;在进行下行转换时,dynamic_cast具有类型检查的功能,比static_cast更安全。

class B {
public:
    int m_iNum;

    virtual void foo();
};

class D : public B {
public:
    char *m_szName[100];
};

void func(B *pb) {
    D *pd1 = static_cast<D *>(pb);
    D *pd2 = dynamic_cast<D *>(pb);
}

在上面的代码段中,如果pb指向一个D类型的对象,pd1和pd2是一样的,并且对这两个指针执行D类型的任何操作都是安全的;但是,如果pb指向的是一个 B类型的对象,那么pd1将是一个指向该对象的指针,对它进行D类型的操作将是不安全的(如访问m_szName),而pd2将是一个空指针。另外要注意:B要有虚函数,否则会编译出错;static_cast则没有这个限制。这是由于运行时类型检查需要运行时类型信息,而这个信息存储在类的虚函数表(关于虚函数表的概念,详细可见)中,只有定义了虚函数的类才有虚函数表,没有定义虚函数的类是没有虚函数表的。

另外,dynamic_cast还支持交叉转换(cross cast)。如下代码所示。

class A {
public:
    int m_iNum;
    virtual void f(){}
};

class B : public A {
};

class D : public A {
};

void foo() {
    B *pb = new B;
    pb->m_iNum = 100;
    D *pd1 = static_cast<D *>(pb); //copile error
    D *pd2 = dynamic_cast<D *>(pb); //pd2 is NULL
    delete pb;
}

在函数foo中,使用static_cast进行转换是不被允许的,将在编译时出错;而使用 dynamic_cast的转换则是允许的,结果是空指针。

reinpreter_cast

用法:reinpreter_cast (expression_r_r)

type-id必须是一个指针、引用、算术类型、函数指针或者成员指针。它可以把一个指针转换成一个整数,也可以把一个整数转换成一个指针(先把一个指针转换成一个整数,在把该整数转换成原类型的指针,还可以得到原先的指针值)。

该运算符的用法比较多。

const_cast

用法:const_cast (expression_r_r)

该运算符用来修改类型的const或volatile属性。除了const 或volatile修饰之外, type_id和expression_r_r的类型是一样的。

常量指针被转化成非常量指针,并且仍然指向原来的对象;常量引用被转换成非常量引用,并且仍然指向原来的对象;常量对象被转换成非常量对象。

Voiatile和const类试。举如下一例:

class B {
public:
    int m_iNum;
}

void foo() {
    const B b1;
    b1.m_iNum = 100; //comile error
    B b2 = const_cast<B>(b1);
    b2. m_iNum = 200; //fine
}

上面的代码编译时会报错,因为b1是一个常量对象,不能对它进行改变;使用const_cast把它转换成一个常量对象,就可以对它的数据成员任意改变。注意:b1和b2是两个不同的对象。

最容易理解的解释:
dynamic_cast: 通常在基类和派生类之间转换时使用;
const_cast: 主要针对const和volatile的转换.
static_cast: 一般的转换,如果你不知道该用哪个,就用这个。
reinterpret_cast: 用于进行没有任何关联之间的转换,比如一个字符指针转换为一个整形数。

(转)优质代码十诫

1.- DRY: Don’t repeat yourself.
DRY是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
DRY这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

2.- 短小的方法.
至少,我们有下面三个不错的理由要求程序员们写下短小的方法。

  1. 代码会变得更容易阅读。
  2. 代码会变得更容易重用(短方法可以减少代码间的耦合程度)
  3. 代码会变得更容易测试。

3.- 良好的命名规范
使用不错的统一的命名规范可以让你的程序变得更容易阅读和维护,当一个类,一个函数,一个变量的名字达到了那种可以“望文生义”的境界话,我们就可以少一些文档,少一些沟通。

4.- 赋予每个类正确的职责
一个类,一个职责,这类规则可以参考一下类的SOLID 法则。但我们这里强调的不是一种单一的职责,而是一个正确的职责。如果你有一个类叫Customer,我们就不应该让这个类有sales 的方法,我们只能让这个类有和Customer有最直接关系的方法。

5.- 把代码组织起来
把代码组织起来有两具层次。
*物理层组织:无论你使用什么样的目录,包(package)或名字空间(namespace)等的结构,你需要把你的类用一种标准的方法组织起来,这样可以方便查找。这是一种物理性质的代码组织。
*逻辑层组织:所谓逻辑层,主要是说,我们如果把两个不同功能的类或方法通过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这就是我们经常见到的程序模块的架构。

6.- 创建大量的单元测试
单元测试是最接近BUG的地方,也是修改BUG成本最低的地方,同样也是决定整个软件质量好坏的成败的地方。所以,只要有可能,你就应该写更多的,更好的单元测试案例,这样当你未来有相应代码改变的时候,你可以很简单知道你代码的改变是否影响了其它单元。

7.- 经常重构你的代码
软件开发是一种持续的发现的过程,从而让你的代码可以跟上最新的实际需求的变化。所以,我们要经常重构自己的代码来跟上这样的变化。当然,重构是有风险的,并不是所有的重构都是成功的,也不是我们随时都可以重构代码。下面是两个重构代码的先要条件,以避免让你引入更多的BUG,或是把本来就烂的代码变得更烂。

  1. 有大量的单元测试来测试。正如前面所说,重构需要用大量的单元测试来做保障和测试。
  2. 每次重构都不要大,用点点滴滴的小的重构来代替那种大型的重构。有太多的时候,当我们一开始计划重构2000行代码,而在3个小时后,我们就放弃这个计划并把代码恢复到原始的版本。所以,我们推荐的是,重构最好是从点点滴滴积累起来的。

8.- 程序注释是邪恶的
这一条一定是充满争议的,大多数程序员都认为程序注释是非常好的,是的,没错,程序注释在理论上是非常不错的。但是,在实际过程序当中,程序员们写出来的注释却是很糟糕的(程序员的表达能力很有问题),从而导致了程序注释成为了一切邪恶的化身,也导致了我们在阅读程序的时,大多数时候,我们都不读注释而直接读代码。所以,在这里,我们并不是鼓励不写注释,而是——如果你的注释写得不够好的话,那么,你还不如把更重要的时间花在重构一下你的代码,让你的代码更加易读,更加清楚,这比会比注释更好。

9.- 注重接口,而不是实现
这是一个最经典的规则了。接口注重的是——“What”是抽象,实现注重的是——“How”是细节。接口相当于一种合同契约,而实际的细节相当于对这种合同契约的一种运作和实现。运作是可以很灵活的,而合同契约则需要是相对需要稳定和不变的。如果,一个接口没有设计好而需要经常性的变化的话,那我们可以试想一下,这代来的后果,这绝对会是一件成本很大的事情。所以,在软件开发和调设中,接口是重中之重,而不是实现。然而我们的程序员总是注重于实现细节,所以他们局部的代码写的非常不错,但软件整体却设计得相对较差。这点需要我们多多注意。

10.- 代码审查机制
所有人都会出错,一个人出错的概率是很大的,两个人出错的概率就会小一些,人多一些,出错的概率就会越来越小。因为,人多了,就能够从不同的角度看待一个事情,虽然这样可能导致无效率的争论,但比起软件产品release后出现问题的维护成本,这点成本算是相当值得的。所以,这就是我们需要让不同的人来reivew代码,代码审查机制不但是一种发现问题的最有效的机制,同时也是一种可以知识共享的机制。当然,对于Code Review来说,下面有几个基本原则:
* 审查者的能力一定要大于或等于代码作者的能力,不然,代码审查就成了一种对新手的training。
* 而且,为了让审查者真正负责起来,而不是在敷衍审查工作,我们需要让审查者对审查过的代码负主要责任,而不是代码的作者。
* 另外,好的代码审查应该不是当代码完成的时候,而是在代码编写的过程中,不断地迭代代码审查。好的实践的,无论代码是否完成,代码审核需要几天一次地不断地进行。