What are the uses of the type `std::nullptr_t`?

Question

I learned that nullptr, in addition to being convertible to any pointer type (but not to any integral type) also has its own type std::nullptr_t. So it is possible to have a method overload that accepts std::nullptr_t.

Exactly why is such an overload required?

Egan

Answer 1

If more than one overload accepts a pointer type, an overload for std::nullptr_t is necessary to accept a nullptr argument. Without the std::nullptr_t overload, it would be ambiguous which pointer overload should be selected when passed nullptr.

Example:

void f(int *intp)
{
    // Passed an int pointer
}

void f(char *charp)
{
    // Passed a char pointer
}

void f(std::nullptr_t nullp)
{
    // Passed a null pointer
}

Anatolic

Can't the ambiguity be solved by casting the nullptr? e.g. f( (int*)nullptr ); f( (char*)nullptr ); ? – Categorical

@Dai: Sure, but that would be clunky for users. – Classroom

These casts can still be used to select one of the other two overloads willingly, though. – Wraparound

What if I have a char* that points to 0? This overloading would fail, wouldn't it? It would get passed to the 2nd version. Both of the first two functions are going to have to make an explicit check that they haven't been passed a null pointer in order to be safe, so you might as well deal with that case in there. If there's some third behavior that you want with the null as an argument, then you could just have void f(void), right? – Thyestes

Answer 2

There are some special cases that comparison with a nullptr_t type is useful to indicate whether an object is valid.

For example, the operator== and operator!= overloads of std::function could only take nullptr_t as the parameter to tell if the function object is empty. For more details you could read this question.

Hunchback

Answer 3

Also, what other type would you give it, that doesn't simply re-introduce the problems we had with NULL? The whole point is to get rid of the nasty implicit conversions, but we can't actually change behaviour of old programs so here we are.

Earthworm

Answer 4

The type was introduced to avoid confusion between integer zero and the the null memory. And as always cpp gives you access to the type. Where as Java only gives you access to the value. It really doesnt matter what purpose you find for it. I normally use it as a token in function overloading.

But I have some issues with the implementation of cpp null const.

• Why didnt they just continue with NULL or null? That definition was already being used for that purpose. What about code that already was using nullptr for something else.

• Not to mention nullptr is just too long. Annoying to type and ugly to look at most times. 6 characters just to default initialize a variable.

• With the introduction of nullptr, you would think zero would no longer be both a integer and null pointer const. However zero still holds that annoying ambiguity. So I dont see the sense then of this new nullptr value. If you define a function that can accept an integer or a char pointer, and pass zero to that function call, the compiler will complain that it is totally ambigious! And I dont think casting to an integer will help.

• Finally, it sucks that nullptr_t is part of the std namespace and not simply a keyword. Infact I am just learning this fact, after how long I have been using nullptr_t in my functions. MinGW32 that comes with CodeBlocks allows you to get away with using nullptr_t with std namespace. Infact MinGW32 allows void* increment and a whole lot of other things.

Which leads me to: cpp has too much denominations and confusion. To the point where code compatibility with one compiler is not compatibility with another of the same cpp version. Static library of one compiler cannot work with a different compiler. There is no reason why it has to be this way. And I think this is just one way to help kill cpp.

Marti