Home » C++ » Why not call nullptr NULL?

Why not call nullptr NULL?

Posted by: admin November 29, 2017 Leave a comment


In C++11 the nullptr keyword was added as a more type safe null pointer constant, since the previous common definition of NULL as 0 has some problems.

Why did the standards committee choose not to call the new null pointer constant NULL, or declare that NULL should be #defined to nullptr?


Stephan T. Lavavej (member of the C++ standard committee) explained that once in a talk (55:35):

While an implementation is allowed to #define NULL nullptr, it would break quite some uses like

int i = NULL;

and apparently there are plenty of those. So they could not force the change.


nullptr is of pointer type , while NULL has the tendency to be integer, and sometimes in overloaded functions, you need to be clear that you are using a pointer and not an integer – this is whennullptr comes in handy.

So to really answer your question, NULL and nullptr serve to different purposes and redefining one to another will probably break a lot of things in the already existent code bases.

Beside that,

check this from Bjarne Stroustrup’s website

Should I use NULL or 0?

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.


Without actually sitting in on the discussion in the standards committee, it’s hard to say for sure, but I would think because it would break some code that uses NULL in a meaning where nullptr isn’t sufficiently compatible. And breaking old code is never a good idea.


NULL is not type safe. For historical reason it was defined as 0 without casting, and the compiler silence warning of casting number to pointer on this special zero.

For instant, you can do:

void* p = 0;

but not this without implicit casting:

void* p = 1234;

the side effect is that it can be abused as number values, as other answer mentioned.

nullptr improve this by enforcing it is a pointer, you can’t assign this to an integer.
Since the behaviour is changed, a new name is created for backward compatibility.

Also note that, nullptr is handled by the compiler, its actual value is not exposed to user (like zero in case of NULL). It’s much easier to have architecture dependent value, say 0xdeadbeef, without affect programmer’s code logic.


Why did the standards committee choose not to call the new null pointer constant NULL

Presumably because the new null pointer is a keyword, and keywords cannot be #defined, so calling it NULL would have made inclusion of any C header likely ill-formed.

or declare that NULL should be #defined to nullptr?

The standards committee does allow NULL to be #defined to nullptr, but it does not require it.

C++11 18.2 Types [support.types]/2:
The macro NULL is an implementation-defined C++ null pointer constant in this International Standard.

C++11 4.10 Pointer conversions [conv.ptr]/1:
A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero or a prvalue of type std::nullptr_t.

Backwards compatibility is not a concern here, any use of NULL that assumes it is a form of the integer 0 is not standard conformant. Implementations might choose not to do it to condone this kind of evil behavior.


Thenullptr is introduced for type safety and for clarity (probably to stop the initialization of non-pointer types using NULL).

The NULL(int type) is not changed to nullptr(pointer type) to avoid confusion and to ensure backward compatibility.

Thus, the standard committee train of thought is probably related to smooth transition from the old to new notation without causing ambiguities or braking any already existing code.


I will demonstrate a case where the decision to define nullptr as a different type helps preventing bugs.

Consider these functions:

void foo(int);
void foo(char *);

int main()
    foo(NULL); // oops

In C++98, the code above calls the foo(int) function, because NULL is replaced by 0, which is most likely not what you intended to.

But if you call foo(nullptr) it calls the correct one — foo(char*).