Do you use NULL or 0 (zero) for pointers in C++?

Question

Here's Stroustrup's take on this: C++ Style and Technique FAQ

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days.

If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, nullptr will be a keyword.

That said, don't sweat the small stuff.

There are a few arguments (one of which is relatively recent) which I believe contradict Bjarne's position on this.

1. Documentation of intent

   Using NULL allows for searches on its use and it also highlights that the developer wanted to use a NULL pointer, irrespective of whether it is being interpreted by the compiler as NULL or not.

2. Overload of pointer and 'int' is relatively rare

   The example that everybody quotes is:

    void foo(int*);
    void foo (int);
   
    void bar() {
      foo (NULL);  // Calls 'foo(int)'
    }
   

   However, at least in my opinion, the problem with the above is not that we're using NULL for the null pointer constant: it's that we have overloads of foo() which take very different kinds of arguments. The parameter must be an int too, as any other type will result in an ambiguous call and so generate a helpful compiler warning.

3. Analysis tools can help TODAY!

   Even in the absence of C++0x, there are tools available today that verify that NULL is being used for pointers, and that 0 is being used for integral types.

4. C++ 11 will have a new std::nullptr_t type.

   This is the newest argument to the table. The problem of 0 and NULL is being actively addressed for C++0x, and you can guarantee that for every implementation that provides NULL, the very first thing that they will do is:

    #define NULL  nullptr
   

   For those who use NULL rather than 0, the change will be an improvement in type-safety with little or no effort - if anything it may also catch a few bugs where they've used NULL for 0. For anybody using 0 today... well, hopefully they have a good knowledge of regular expressions...

Use NULL. NULL shows your intent. That it is 0 is an implementation detail that should not matter.

I always use:

• NULL for pointers
• '\0' for chars
• 0.0 for floats and doubles

where 0 would do fine. It is a matter of signaling intent. That said, I am not anal about it.

I stopped using NULL in favor of 0 long ago (as well as as most other macros). I did this not only because I wanted to avoid macros as much as possible, but also because NULL seems to have become over-used in C and C++ code. It seems to be used whenever a 0 value is needed, not just for pointers.

On new projects, I put this in a project header:

static const int nullptr = 0;

Now, when C++0x compliant compilers arrive, all I have to do is remove that line. A nice benefit of this is that Visual Studio already recognizes nullptr as a keyword and highlights it appropriately.

    cerr << sizeof(0) << endl;
    cerr << sizeof(NULL) << endl;
    cerr << sizeof(void*) << endl;

    ============
    On a 64-bit gcc RHEL platform you get:
    4
    8
    8
    ================

The moral of the story. You should use NULL when you're dealing with pointers.

1) It declares your intent (don't make me search through all your code trying to figure out if a variable is a pointer or some numeric type).

2) In certain API calls that expect variable arguments, they'll use a NULL-pointer to indicate the end of the argument list. In this case, using a '0' instead of NULL can cause problems. On a 64-bit platform, the va_arg call wants a 64-bit pointer, yet you'll be passing only a 32-bit integer. Seems to me like you're relying on the other 32-bits to be zeroed out for you? I've seen certain compilers (e.g. Intel's icpc) that aren't so gracious -- and this has resulted in runtime errors.