f (p == NULL), if (p == 0) 还是 if(p) ?----再论空指针检测问题

转载请注明出处:　http://blog.csdn.net/wingfiring

某些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 ! 和operator bool.虽然重载operator bool也是危险的，但是现在技术上可以绕过这一点，就是重载一个unspecified_boolean的办法，类似实现如下：
template
    class unspecified_boolean_imp
    {
        struct Tester{    void dummy(){}        };
        typedef void (Tester::*unspecified_boolean_type)();   
    public:
        operator unspecified_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了．