NULL v. zero [LWN.net]

NULL v. zero

Posted Jul 16, 2004 19:40 UTC (Fri) by Ross (subscriber, #4065)
In reply to: NULL v. zero by ikm
Parent article: NULL v. zero

I disagree that the use of 0 for everything means that C++ is stongly typed.
It seems backwards to me. A srongly typed language should be able to tell
the type of a constant without looking at the lhs of an assignment or the
parameter type in a function call. I don't believe you that C++ magically
knows which one... I think it evaluates it as an int, and then converts to
a pointer on assignment. Where this gets really ugly is with overloaded
functions and operators... if there is an int version and say, an int *
version, which one do you mean to call with a naked 0?

(Log in to post comments)

NULL v. zero

Posted Jul 16, 2004 20:15 UTC (Fri) by ikm (subscriber, #493) [Link]

First of all, it is the fact that the language is strongly typed that allows it using 0 for anything, but not the opposite.

There is no magic. A zero constant may be implicitly casted either to a null pointer, or to a zero integer. The compiler deduces which cast is required judging by the target type. An integer can not be implicitly casted to a null pointer, as well as any non-zero integer constant. Only a zero integer constant may be casted to a pointer. It is quite simple really.

When the target type is ambiguous (e.g. with overloaded functions), the compiler will stop with an error. In this case you will have to cast your zero either to an integer type or to a pointer type explicitly. This behaviour is common with overloaded functions, and is nothing special for pointers.

NULL v. zero

Posted Jul 17, 2004 4:32 UTC (Sat) by Ross (subscriber, #4065) [Link]

But what do you mean by target type? LHS? If so, this goes against
fundamental aspects of the language. The evaluation of the RHS should
not be affected by the type of the LHS. The conversion should only
happen just before the assignment. And if such conversion happens, that
is an implicit conversion -- an implicit cast. That's not strong type
checking. And my point is that the RHS may be more than a simple
unadorned zero. When that is the case it would be nice to know ahead of
time if the type is an integer or a pointer so that it could warn about
improper manipulation of pointers (multiplying pointers for example).
Maybe that's a contrived corner case but I still see it as an ugly aspect
of the language.

NULL v. zero

Posted Jul 17, 2004 4:41 UTC (Sat) by Ross (subscriber, #4065) [Link]

Wait. I think I just understood what you mean:

char *bob=0*0;

would not compile as 0*0 is an integer expression. The implicit conversion
is only applied for a naked constant.

Then I retract my statement about the compiler not being able to warn in
some cases. But I continue to think this is rather strange for a language
that claims to be strongly typed. (For example the removal of implicit
conversions of char constants was a good thing... I wish C could shed that
"feature" as well.)

NULL v. zero

Posted Jul 17, 2004 11:08 UTC (Sat) by ikm (subscriber, #493) [Link]

No,

char * bob = 0*0;

will compile. Everything that evaluates to a zero at compile time will work. That's what I actually meant by saying "zero constant". The fact that it is possible to assign various constant expressions with the zero result to pointers looks like a misfeature, but it is minor at best.

On the other hand,

int i = 0;

char * bob = i;

will not compile, as 'i' does not qualify as something that evaluates to a zero at compile time.