Effective C++ 2e Item25

原创 2001年07月15日 18:27:00

条款25: 避免对指针和数字类型重载

快速抢答:什么是“零”?

更明确地说,下面的代码会发生什么?

void f(int x);
void f(string *ps);

f(0);                        // 调用f(int)还是f(string*)?

答案是,0是一个int——准确地说,一个字面上的整数常量——所以,“总是”f(int)被调用。这就是问题所在:因为不是所有的人总是希望它这样执行。这是C++世界中特有的一种情况:当人们认为某个调用应该具有多义性时,编译器却不这么干。

如果能想办法用符号名(比如,NULL表示null指针)来解决这类问题就好了,但实现起来比想象的要难得多。

最先想到的应该是声明一个称为NULL的常量,但常量要有类型,NULL的类型应该是什么呢?它要兼容于所有的指针类型,但满足条件的唯一一个类型是void*,而且,要想把void*指针传给某类型的指针,必须要有一个显式的类型转换。这样做不仅很难看,而且乍看不比最初的情况好到哪儿去:

void * const NULL = 0;             // 可能的NULL定义

f(0);                              // 还是调用f(int)
f(static_cast<string*>(NULL));     // 调用f(string*)
f(static_cast<string*>(0));        // 调用f(string*)

不过细想一下,用NULL来表示一个void*常量的方法还是比最初要好一点,因为如果能保证只是用NULL来表示null指针的话,是可以避免歧义的:

f(0);                              // 调用f(int)
f(NULL);                           // 错误! — 类型不匹配
f(static_cast<string*>(NULL));     // 正确, 调用f(string*)

至少现在已经把一个运行时的错误(对0调用了“错误的”f函数)转移成了一个编译时的错误(传递一个void*给string*参数)。情况稍微有点改善(见条款46),但需要进行类型转换还是令人讨厌。

如果想可耻地退回去求助于欲处理,你会发现它也解决不了问题,因为最明显的办法不外乎:

#define NULL 0

#define NULL ((void*) 0)

第一种办法只不过是字面上的0,本质上还是一个整数常量(如果你记得的话,还是最初的问题);第二种方法则又把你拉回到“传void*指针给某种类型的指针”的麻烦中。

如果对类型转换的规则有研究,你就会知道,C++会认为“从long int 0到null指针的转换”和“从long int到int的转换”一样,没什么不妥的。所以可以利用这一点,将多义性引入到上面那个你可能认为有“int/指针”问题的地方:

#define NULL 0L            // NULL现在是一个long int

void f(int x);
void f(string *p);

f(NULL);                   // 错误!——歧义

然而,当想重载long int和指针时,它又不起作用了:

#define NULL 0L

void f(long int x);        // 这个f现在的参数为long
void f(string *p);

f(NULL);                   // 正确, 调用f(long int)

实际编程中,这比把NULL定义为int可能要安全,但它无非只是在转移问题,而不是消除问题。

这个问题可以消除,但需要使用C++语言最新增加的一个特性:成员函数模板(往往简称为成员模板)。顾名思义,成员函数模板是在类的内部为类生成成员函数的模板。拿上面关于NULL的讨论来说,我们需要一个“对每一个T类型,运作起来都象static_cast<T*>(0)表达式”的对象。即,使NULL成为一个“包含一个隐式类型转换运算符”的类的对象,这个类型转换运算符可以适用于每种可能的指针类型。这就需要很多转换运算符,但它们可以求助于C++从成员模板生成:

// 一个可以产生NULL指针对象的类的第一步设计
class NullClass {
public:
  template<class T>                       // 为所有类型的T
    operator T*() const { return 0; }     // 产生operator T*;
};                                        // 每个函数返回一个
                                          // null指针
                                          //

const NullClass NULL;             // NULL是类型NullClass
                                  // 的一个对象

void f(int x);                    // 和以前一样

void f(string *p);                // 同上

f(NULL);                          // 将NULL转换为string*,
                                  // 然后调用f(string*)

这是一个很好的初步设计,但还可以从几方面进行改进。第一,我们实际上只需要一个NullClass对象,所以给这个类一个名字没必要;我们只需要定义一个匿名类并使NULL成为这种类型。第二,既然我们是想让NULL可以转换为任何类型的指针,那就也要能够处理成员指针。这就需要定义第二个成员模板,它的作用是为所有的类C和所有的类型T,将0转换为类型T C::*(指向类 C里类型为T的成员)。(如果你不懂成员指针,或者你从没听说过,或很少用,那也不要紧。成员指针可以称得上是稀有动物,是很少见,也许很多人从来没用过它。对此好奇的人可以参考条款30,那儿对成员指针进行了较详细的讨论。)最后,要防止用户取NULL的地址,因为我们希望NULL的行为并不是象指针那样,而是要象指针的值,而指针的值(如0x453AB002)是没有地址的。

所以,改进后的NULL的定义看起来就象这样:

const                             // 这是一个const对象...
class {
public:
  template<class T>               // 可以转换任何类型
    operator T*() const           // 的null非成员指针
    { return 0; }                 //

  template<class C, class T>      // 可以转换任何类型
    operator T C::*() const       // 的null成员指针
    { return 0; }

private:
  void operator&() const;         // 不能取其地址
                                  // (见条款27)

} NULL;                           // 名字为NULL

这就是所看到的真实的代码,虽然在实际编程中有可能想给类一个名字。如果不给名字,编译器里指向NULL类型的信息也确实很难理解。

成员模板的用法的另一个例子参见条款M28。

重要的一点是,以上所有那些产生正确工作的NULL的设计方案,只有在你自己是调用者的时候才有意义。如果你是设计被调用函数的人,写这样一个给别人使用的NULL其实没有多大的用处,因为你不能强迫你的调用者去使用它。例如,即使为你的用户提供了上面开发的那个NULL,你还是不能防止他们这样做:

f(0);                  // 还是调用f(int),
                       // 因为0还是int

它还是和本条款最前面的出现的问题一样。

所以,作为重载函数的设计者,归根结底最基本的一条是,只要有可能,就要避免对一个数字和一个指针类型重载。

《Effective C++》学习笔记——条款31

《Effective C++》学习笔记——条款31:将文件间的编译依存关系降至最低
  • lx417147512
  • lx417147512
  • 2015年06月15日 13:51
  • 1367

《Effective C++》让自己习惯C++:条款1-条款4

《Effective C++》条款1到条款4。基本是总结C++的一些特点,尤其是不同于C语言的特点。...
  • KangRoger
  • KangRoger
  • 2014年12月13日 19:26
  • 2351

effective C++ 目录(第三版)

我把目录整理一下,方便在以后工作中查看。 条款01:视C++为一个语言联邦 条款02:尽量以const,enum,inline替换#define 条款03:尽可能使用const 条...
  • u010889616
  • u010889616
  • 2015年12月24日 20:12
  • 519

《Effective C++》读后感

几天前,我曾在微信朋友圈中发了一条消息: 和大牛之间的差距就是这一个书架。 图片来自于微信公众号“二爷鉴书”的分享。 我时常纠结于自己的技术为什么进步的这么慢,大概就是书读的太少、思考的太少。 《E...
  • Since20140504
  • Since20140504
  • 2016年06月27日 12:13
  • 7546

《Effective C++》:条款44-条款45

条款44将与参数无关的代码抽离templates 条款45运用成员函数模板接受所有兼容类型...
  • KangRoger
  • KangRoger
  • 2015年03月12日 22:01
  • 1484

【C++】《Effective C++》读书笔记汇总

我之前边读《Effective C++》边写下每个条款的读书笔记,这一版是C++11之前的版本。这里我将每个条款令我印象深刻的点小结一下。 1、C++包括:Plain C(面向过程)、OOP(面向对...
  • lpsl1882
  • lpsl1882
  • 2016年04月06日 11:14
  • 2257

《Effective C++》学习笔记(六)

原创文章,转载请注明出处:http://blog.csdn.net/sfh366958228/article/details/38922567 前言 今天学的条款都是出自于《设计与声明》这一张,...
  • sfh366958228
  • sfh366958228
  • 2014年08月29日 20:00
  • 746

《Effective C++》:条款41-条款42

条款41了解隐式接口和编译期多态 条款42了解typename的双重意义条款
  • KangRoger
  • KangRoger
  • 2015年03月10日 22:13
  • 1204

《Effective C++》:条款28-条款29

条款28避免返回handles指向对象内部成分:指的是不能返回对象内部数据/函数的引用、指针等。 条款29为异常安全而努力是值得的:指的是要有异常处理机制,避免发生异常时造成资源泄露等问题。...
  • KangRoger
  • KangRoger
  • 2015年02月19日 19:47
  • 1372

《Effective C++》资源管理:条款13-条款15

在系统中,资源是有限的,一旦用完必须归还给系统,否则可能会造成资源耗尽或其他问题。例如,动态分配的内存如果用完不释放会造成内存泄漏。 这里说的资源不仅仅是指内存,还包括其他,例如文件描述符、网络连接、...
  • KangRoger
  • KangRoger
  • 2015年01月14日 21:46
  • 1285
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Effective C++ 2e Item25
举报原因:
原因补充:

(最多只允许输入30个字)