Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!mips!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!haven!decuac!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.lang.c++
Subject: Re: offsetof, pointer to member. (Was Re: references ...)
Message-ID: <1447@tkou02.enet.dec.com>
Date: 9 Apr 90 06:06:46 GMT
References: <5764@videovax.tv.tek.com> <15126@cbnews.ATT.COM> <10647@alice.UUCP> <1431@tkou02.enet.dec.com> <10677@alice.UUCP>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 30

In article <10677@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>In article <1431@tkou02.enet.dec.com>, diamond@tkou02.enet.dec.com (diamond@tkovoa) writes:
>>In article <26191B56.143@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes:
>>>
>>>The reason is that this is a clever way of reserving the value 0 for use
>>>as a *NULL* for pointer-to-data-member types.
>>
>> Interesting.  However, would it not be equally clever, and faster in CPU
>> time, to reserve the value -1 for that purpose instead?
>
>In both C and C++, 0 is the only pointer value that is guaranteed
>to be distinct from the address of any object.
>It would be decidedly weird to do something inconsistent with
>that for pointers to members.

I can hardly believe my eyes.  Andrew Koenig confused a null pointer
with a run-time entity of all-bits-0 ?

As a matter of internal implementation and efficiency, all-bits-1
(on two's complement machines anyway) seems better, so that games
don't have to be played with the representations of actual offsets.






-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
This_blank_intentionally_left_underlined________________________________________