某些C/C++编程的书中,曾经提到如何判断指针是否为空的问题.很显然,if (p == NULL), if (p == 0) 和if(p),都能够完成这一任务,差别在于可读性方面.我们分别加以讨论.
1. if (p == NULL)
相当多的文章建议采用,他们中的部分人甚至认为,其他做法都是错误的.这个形式一个变种是 if (NULL == p),虽然略显怪异,但是,万一我们误将==写成了=,编译器通常都会给出编译错误,从而防止键入的错误.拥护这一方案的人认为,NULL可以明确地表达出p 是一个指针,而不是整数或其他什么东西.有助于我们理解代码.然而,反对者也众多,包括C++之父B.S.反对的主要根据是,NULL并不是语言的一部分,通常,它是由一个宏定义而来的:
#define NULL ((void*)0)
一般来说,NULL其实可以工作的很好,但是,宏的出身,让它不让人喜欢.另外,它也确实有些现实的问题,典型的,成员指针的问题.假设有类型A,
typedef void (A::*FUNT)();
现在,FUNT定义成一个成员函数指针类型了.假设有FUNT fun = ...
对于if (fun == NULL)将会导致编译失败.原因在于FUNT和void*之间不存在类型转换.不仅仅成员函数存在这个问题,普通函数指针也可能存在这个问题.
那么,我们改变NULL的定义呢?尝试这样定义:
#define NULL (0)
或者
#define NULL 0
这也可能存在问题.NULL这个名字意味着自己是个指针,只允许指针和NULL比较,然而事实上却并非如此.这有欺骗的嫌疑.许多人认为,欺骗不可接受,暴露问题比欺骗要好得多.这种欺骗导致编译器无法提供恰当的帮助.
2. if (p == 0)
包括B.S在内的许多人也推荐这种方式----尽管他们大多认为这个方案并不完美.首先,语言内部对于常量0有特殊的处理,因此,第一种选择中可能遇到的和函数或成员函数指针比较失败的问题可以解决.另一方面,它没有强调自己必须和指针比较,因此,也不存在欺骗.而且,因为这种方式受语言支持,每个C++ 程序员都会熟悉这一方法,而不会觉得难以理解.并且,一个新的语言改进正在进行,会为语言提供一个nullptr的关键字,专门用来和各种指针比较.但目前的语言实现基本上还不支持这一特性.
3．if (p)
许多C++的铁杆或资深用户对前两个方案嗤之以鼻.他们认为这个方案正确,简单,有效. 另外,这一方案可以有效地应用到所谓smart_ptr上去.而1和2方案往往会带来潜在的不安全因素.假设,我们现在有一个smart_ptr类,为了支持第一种语法,我们需要为之定义一个全局的比较函数.但是，这也意味着要提供一系列长相难看（参数类型不对称）的重载，而且，需要花费很多精力．并且，难以提供一个完全一致的实现.
我们看一下，为了支持smart_ptr,不同方案分别需要做些什么．
为方案1,我们要定义：
bool operatro ==( const type& L, void* null);
bool operatro ==( void* null, const type& R);
同样，还需要重载operator !=;
这里的问题是，smart_ptr我们本来不指望和任何void指针比较相等的，但是现在不得不允许了．也就是说，我们可以和一个非NULL的void指针比较了．而我们的本意是：查询这个指针是不是空．
方案２存在同样的问题，而且更严重．我们可能和任意整数比较了．而对于普通的指针，和非0常量比较会编译失败的．
另一个手段，借助于隐式转换，但是那更加不安全．
在第三个方案中，我们通常会重载operator ! 和operatorbool.虽然重载operator bool也是危险的，但是现在技术上可以绕过这一点，就是重载一个unspecified_boolean的办法，类似实现如下：
template
classunspecified_boolean_imp
{
structTester{ void dummy(){} };
typedefvoid (Tester::*unspecified_boolean_type)();
public:
operatorunspecified_boolean_type() const THROW0() {
return static_cast(*this).operator!() ? 0 : &Tester::dummy;
}
protected:
unspecified_boolean_imp(){}
~unspecified_boolean_imp(){};
};
这样，我们可以安全使用if (p)的语法而不必担心被误用．
第三个方案常见于GP代码．然而，拥护1,2方案的人往往反对，认为3不利于阅读，过于技巧化．而3的拥护者认为，3明显是一种更务实有效的做法，可以使得实现简单明了，而且牢靠．
那么回顾一下我们的意图：查询指针是不是空．那么为什么不提供一个查询的函数呢？把差异封装掉不是很好？
于是作下述尝试：
if (is_nullptr(p));
嗯，我觉得这样的代码比if (p == NULL)更加直白．如果is_nullptr定义成宏，可以这样提供：
#define IS_NULLPTR(x) ((x) == 0)
可是，我不喜欢宏，而且，我觉得，宏能够帮我做的事情太少，例如，如果p是一个int,编译器无声无息地成功．我觉得，很明显地is_nullptr对于非指针类型应该给个编译错误．事情落到了template头上：
template bool is_nullptr(T* p){
return !p;
}
现在，我可以安心地写if (is_nullptr(p))了，如果p是int类型，会编译出错．但是，还有两个问题没有解决．一个是smart_ptr，另一个是成员函数指针. smart_ptr其实很简单,重载就是了
template
bool is_nullptr(const smart_ptr& p){ return !p;}
借助于traits技术来维护concept，事实上，可以做得更好,我们只需要一行额外代码，在smart_ptr的定义中加入：
enum { is_pointer = 1};
就足矣．即使我们无法修改smart_ptr,我们仍然有后路，不是吗？如果第三方的smart_ptr不支持if (p)这样的语法，但是，通过重载is_nullptr，我们可以为所有的可能提供唯一的使用形式．我喜欢这种简单性．
函数指针不需要我们做特别的处理就已经支持了．现在处理成员函数指针：
template
bool is_nullptr( T U::* x)
{
return !x;
}
幸运的是，它可以工作．无论是针对成员函数还是成员数据．而且，也无视函数的参数列表．曾经在实现变长template参数地狱中幸存的人们，是不是觉得世界太不公平了？^_^
对于函数，这里的Ｔ不仅仅是返回值，实际上是一个函数定义．不过，我不确定这是否确实符合ISO标准．不过没关系，大不了重回地狱，I will be back!
你可以批评我的巴洛克倾向，我要开始享受静态类型安全的is_nullptr了．
