Reputation: 58868
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 #define
d to nullptr
?
Upvotes: 74
Views: 7444
Reputation: 50053
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.
Upvotes: 77
Reputation: 2246
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 when nullptr
comes in handy.
So to really answer your question, NULL
and nullptr
serve two different purposes and redefining one to another will probably break a lot of things in 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.
Upvotes: 43
Reputation: 2107
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*).
Upvotes: 2
Reputation: 81349
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.
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.
Upvotes: 3
Reputation: 6467
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.
Upvotes: 0
Reputation: 3911
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.
Upvotes: 9
Reputation: 129374
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.
Upvotes: 7