Null pointer naming

Hi

This post is regarding the proposed name for the null pointer - nullptr (see http://www.open-std.org/jtc1/sc22/wg...004/n1601.pdf).
I am wondering why it has not been considered using the already existing keyword "void" as the name for the null pointer.

In my head the word void perfectly describes what a null pointer is pointer at - namely absolutely nothing. And since it already is a keyword it has the benefit of not introducing problems with existing code. On the downside it does make the "void" keyword more ambiguous.

So my question to the board is: Is there any technical (compiler) reason for not using this keyword to assign a null value to a pointer?

regards
als

>So my question to the board is: Is there any technical (compiler)
>reason for not using this keyword to assign a null value to a pointer?

Code:

int main()
{
  foo ( void );
}

What is foo?

*head asplodes after trying to answer Prelude's question*

i hate foo

it's just a junk name

well, foo is a compile-time error

Anyways, the reason you can't is because void is a reserved word. You cannot use reserved words to name your objects.

You can name your pointer Void though... but if you do I hope you burn in hell

>Anyways, the reason you can't is because void is a reserved word.
I think the question was regarding a proposed addendum to the standard. Rather than defining a new reserved word, the OP's suggestion is to simply reuse void. It's not a bad question, but aside from being terribly ambiguous in certain situations, it would break a *lot* of existing code. It also introduces countless special cases for an implementation to differentiate between the void type and the void object; which a new reserved word could easily avoid.

Oh, I see your point. Just read the document.

Well... let me see if I understand the meaning of your initial question then... What is foo?

Answer: Foo is ambiguous. It can be a function declaration or a function call.

Is that it?

How about a new keyword "Is" and a new keyword "Nothing". That way, you could code something like this:

Code:

int main() {
    void* vp = Nothing;

    if (vp Is Nothing) {
        cout << "It's nothing, really." << endl;
    }
    return 0;
}

Also, consider what would happen if we added the keywords "Then" and "End If" to be used instead of the opening and closing curly braces. Also, the parens around the if condition are really unneeded, so lets say they are optional. Now we have:

Code:

int main() {
    void* vp = Nothing;

    if vp Is Nothing Then
        cout << "It's nothing, really." << endl;
    End If
    return 0;
}

Next we can get rid of semi-colons, as long as we support line-continuation characters. After all, usually you fit an entire statement on a single line anyway, so now this gets rid of a bunch of ugly and unnecessary characters in the code:

Code:

int main() {
    void* vp = Nothing

    if vp Is Nothing Then
        cout << "It's nothing, really." << endl
    End If
    return 0
}

Next lets say that we want to get rid of curly braces in general, in favor of something a little more descriptive. I propose something like this:

Code:

Function main() As integer {
    void* vp = Nothing

    if vp Is Nothing Then
        cout << "It's nothing, really." << endl
    End If
    return 0
End Function

Also, if we can get rid of the void*, that would be nice also. Maybe we can come up with some kind of keyword that just means we're declaring a variable, without actually specifying the type (that's basically what void* is anyway). And then declaring the type would be optional. Ok so our new keyword will be...oh I don't know how about "Dim". Could be anything really, but just for illustrative purposes...so lets see what we have now:

Code:

Function main() As integer {
    Dim vp = Nothing

    if vp Is Nothing Then
        cout << "It's nothing, really." << endl
    End If
    return 0
End Function

Ok, we're almost done. But what should we do with cout? I really don't like those << and >>. I mean, is that some kind of bit-shift operation or what's going on? I think we would be better off if there was some kind of object that had a WriteLine function, just so we were clear on exactly what's happening. Maybe make a Console object...and put that in a System namespace. Ok, so here it is:

Code:

Function main() As integer {
    Dim vp = Nothing

    if vp Is Nothing Then
        System.Console.WriteLine("It's nothing, really.")
    End If
    return 0
End Function

There, that looks good. Maybe we should ship this off to a c++ comittee to see if they can't do something with it.

Foo is a macro that resolves to a prototype for a function bar:

Code:

# define foo(X) X bar(X)

Actually I thought that foo could be a function declaration (or maybe even a function call to a function that takes no parameters), but gcc complains:

out.c:2: error: syntax error before "void"

So I guess that it has to be a function call taking void, which in this case would be NULL.

Just out of curiosity, what is the reasoning for why we need a keyword for NULL? Isn't NULL good enough?

And by the way, wow, I just realized that C/C++ is a nutty language. Because actually what I realized is that foo(void); is really a prototype for this function: int bar(int x). Check this out:

Code:

# define foo(X) X bar(X);
# define void int

int main() {
    foo(void);
    return 0;
}

int bar(int x) {
    printf("Called foo\n");
    return 0;
}

It seems like redefining keywords should be disallowed...

I believe Prelude asked that in the context of void being a null pointer.

Yes, she did, but in order for foo(void) to be ambigous (when void is also NULL), it would have to have some legitimate meaning in the normal c/c++ sense. Wouldn't it?

>Isn't NULL good enough?
Not in C++. NULL is a symbolic constant for the integer 0. Consider an overloaded function that can take either a pointer or an integer and you'll see one of the problems with NULL in C++. There's a cult out there that gets their kicks from thinking of ways to have a true null pointer object. I won't deny that it's an interesting, if silly, exercise, but it's been explored to death at this point.

But if you realize it was in the context of void meaning a null pointer, why did you test this on your compiler? It is obvious your compiler cannot be used. As far as it is concerned, void is not a null pointer.