Mail Archives: djgpp-workers/1998/03/26/03:14:52
DJ Delorie wrote:
> The problem is ANSI C++ programs - the C++ language is expected to be
> a superset of ANSI C. The C version of the macro works for C++ also,
> so why add complexity where it isn't needed? Why have a symbol that
> has a different set of semantics depending on the language when you
> don't need to? My opinion is that this discussion has taken more
> effort than the results warrant. DJGPP shouldn't have to change to
> adapt to third-party libraries when DJGPP is in compliance with the
> published specifications.
First question: is __null part of the C++ standard of november 1997?
I've done last night a considerable effort to find something about it,
but without luck.
So I deduced this from the 2.8.0 compiler sources:
__null is a cast from 0 to a pointer type pointing to an undetermined
type (not even void). AFAIK it is a constant rvalue, which makes it
suitable as definition of NULL.
DJ's remark seems to imply otherwise (a modifyable lvalue, which makes a
large difference), so, I have to check whether this holds a truth.
[speculation] The advantage of such a value for NULL is that you can
only use it as a pointer, and therefore not assign it to an integer
type, what WAS possible with NULL (=0)
> Comparison of different pointer types? Once NULL has a type, there
> are *less* things you can compare it against, not more.
Type-correctness is somewhat the spirit of C++.
> Some other things:
>
> 1. WHY DO WE NEED THIS? The "0" definition is perfectly fine, and has
> worked for what, twenty years or so?
The reason I mentionned under [speculation] seems a good one, of course
only for C++ as C does not define a __null. BTW __null does not seem to
be a variable or a constant, but it is a reserved word seeming to
designate a value with certain properties, much like ''this'' is used in
member functions.
> 2. "NULL = foo;" would suddenly start working.
That would become: "__null = foo;"
Would it work? I cannot test right now, but the first answer that
crosses my mind is: this cannot be true. The second: If it would be
true, couldn't this be a compiler bug (Eli, a real bug ;-) ). It just
contradicts the meaning given to introduce such a symbol.
> 3. ANSI C explicitly states that NULL must be one of the following: 0,
> 0L, or (void *)0.
I read in one of the latest C drafts (yes, a draft, hence no accepted
standard) that (void*)0 is NOT an acceptable definition for NULL, but 0,
0L, 0LU and even, but not for us, 0LLU are.
But as __null is NOT C, but C++ this does not matter.
My conclusion:
When __null is part of the C++ standard OR it will become documented as
a gnu extension, go for it as new value of NULL for C++.
BTW:
To the person who started this thread (I lost track of who that was):
You should include standard C headers before standard C++ headers, and
the latter before any third party headers. This will in all cases avoid
redefinition warnings when the third party headers are written
correctly. And, IIRC, this practice is recommended in the C standard.
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/
- Raw text -