nullptr has type std::nullptr_t. It's implicitly convertible to any pointer type. Thus, it'll match std::nullptr_t or pointer types in overload resolution, but not other types such as int.

0 (aka. C's NULL bridged over into C++) could cause ambiguity in overloaded function resolution, among other things:

f(int);
f(foo *);

(Thanks to Caleth pointing this out in the comments.)

In C++11 and beyond, a pointer that is ==NULL will also ==nullptr and vice versa.

Uses of NULL other than comparing with a pointer (like using it to represent the nul byte at the end of a string) won't work with nullptr.

In some cases, NULL is #define NULL 0, as the integer constant 0 is special-cased in C and C++ when you compare it with pointers. This non-type type information causes some problems in both C and C++, so in C++ they decided to create a special type and value that does the same thing in the "proper" use cases, and reliably fails to compile in most of the "improper" use cases.

Insofar as your C++ implementation is compatible with the C implementation you are interoping with (very rare for this not to be true), everything should work.

To be very clear, if ptr is any kind of pointer, then the following expressions are equivalent in C++:

ptr == nullptr
ptr == NULL
ptr == 0
!ptr

As are the following:

ptr = nullptr
ptr = NULL
ptr = 0

and if X is some type, so are the following statements:

X* ptr = nullptr;
X* ptr = NULL;
X* ptr = 0;

nullptr differs when you pass it to a template function that deduces type (NULL or 0 become an int unless passed to an argument expecting a pointer, while nullptr remains a nullptr_t), and when used in some contexts where nullptr won't compile (like char c = NULL;) (note, not char* c=NULL;)

Finally, literally:

NULL == nullptr

is true.

The NULL constant gets promoted to a pointer type, and as a pointer it is a null pointer, which then compares equal to nullptr.

Despite all this, it isn't always true that:

 foo(NULL)

and

 foo(nullptr)

do the same thing.

void bar(int) { std::cout << "int\n"; }
void bar(void*) { std::cout << "void*\n"; }
template<class T>
void foo(T t) { bar(t); }
foo(NULL);
foo(nullptr);

this prints int for NULL and void* for nullptr.

Let's further say that, because of limitations with some of the tools I have that don't support any standards newer than C++03, I have this code in a header:

This is a fantastically bad idea.

The expression (0) is (more or less) equivalent to the C++ definition of the NULL. The thing is, nullptr was invented specifically to deal with shortcomings of the NULL.

Therefore, pretending that they are in some way equivalent will only confuse readers. It will make people used to C++11 write code that has different behavior when compiled on C++03 compilers. For example:

void foo(int);
void foo(Bar*);

foo(nullptr);

C++11 tells us that this must call foo(Bar*). But your C++03 macro will instead call foo(int). Since foo(NULL) would cause the same problem, nullptr was invented to stop that.

So having C++03 code that looks like C++11 code but behaves differently is a terrible idea.

nullptr, by design, pretty much never needs to be cast to a specific pointer type. The only exception is if you're calling some kind of function of the form:

template<typename T>
void foo(T* p);

But even then, you can just use foo<ActualType>(nullptr) and get the same effect as foo(static_cast<ActualType*>(nullptr)).

Your not-nullptr needs casting in the same circumstances that NULL does. Indeed, since it is essentially equivalent to NULL, you should just use NULL. And therefore, you have all of the caveats that NULL has.

And FYI: it's pretty much impossible to create a type in C++03 that has identical behavior to C++11's nullptr_t type. You can get close, by using implicit conversions and so forth. But there will always be corner cases where it doesn't work.

So stop promising nullptr behavior that you cannot ensure.