Re: private types

["Peter C. Chapin" <pchapin@sover.net>]

Maciej Sobczak <no.spam@no.spam.com> wrote in
news:dvlu9d$mg6$1@sunnews.cern.ch: 

> Where did you read this?
> NULL is not depreciated. It's defined in the <cstddef> header to be a 
> null-pointer constant, which is any integral const expression that 
> evaluates to 0. Possible definition is:
> 
> #define NULL 0
> 
> Note: the following is explicitly prohibited:
> 
> #define NULL (void*)0

This defintion of NULL is not workable in C++. This is because C++ does 
not allow pointers to void to be put into other pointer types without a 
cast. If the above definition was used the following would be an error:

int *p = NULL;

Thus in C++, NULL must be defined as the literal "0". Note that this 
issue does not come up in C because C's type system is more permissive. 
Thus the (void*)0 is often used in C.

Because "NULL" just expands to "0" in C++, code using NULL can at times 
be misleading. For example consider

void f(int);
void f(char *);

f(NULL);  // Ambiguous, could call either f(int) or f(char *).

This is a surprising error. Other surprises come up when passing NULL to 
functions taking a variable number of arguments. Type checking is 
essentially turned off for the variable arguments and thus if integers 
and pointers have different representations or if the NULL pointer must 
be handled in a special way (not all bits zero), errors can occur

printf("The address is: %p\n", NULL);

In C++ this passes the integer zero to printf, not a pointer. The 
compiler can't understand that "0" is a null pointer constant in this 
context because it doesn't know what type the second argument to printf 
is supposed to be.

For these reasons many C++ experts recommend using "0" explicitly to 
represent NULL pointers and not the symbol NULL. This makes the problems 
above more apparent in the source and thus more likely that the 
programmer will notice them.

Peter