Topic: 0P (was: conformance of #define NULL __builtin_null_pointer
Author: gordan.palameta@canrem.com (Gordan Palameta)
Date: Sat, 16 Oct 93 00:45:00 -0400 Raw View
-> In article <60.1230.4352.0N186016@canrem.com>
-> gordan.palameta@canrem.com (Gordan Palameta) writes:
-> >How about simply defining 0P as an explicit null pointer, by
-> >analogy with 0L and 0U?
-> >
->
-> What's really needed is a requirement (in the C++ standard) that NULL
-> (as defined in the standard header files) is compatible with all
-> pointer types but *incompatible* with all integral types.
But there is no way to #define such a restrictive NULL (unless, of
course, you invent something like 0P).
Scott Meyers goes so far as to recommend avoiding overloading f(int) and
f(char *) because of this. See example #25 in his book, which explains
in detail why you can't invent a generalized NULL with a definition
other than plain old 0.
But in any case, keep NULL as 0, I've seen a bunch of old code that
uses NULL for integer 0 or '\0' (sad but true).
I rather like 0P. Breaks no code, introduces no new keywords.
How about this "definition":
- no such thing as 1P or -42P, just 0P
- in a context requiring pointer or pointer-to-member,
acts just as if "0" had been written in the source code.
- in a context requiring an integral or floating point type,
disallowed unless an explicit cast is used. In the
presence of a cast, behaves as if "0" had been written
in the source code, eg.
float f = 0P; // error
float f = (float)0P; // 0.0F
- in an ambiguous context, eliminates the integral types
void foo(int);
void foo(char *);
void goo(int *);
void goo(char *);
foo(0); // int
foo(0P); // char *
goo(0P); // just like goo(0), error