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