From -8151891046577251251
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-09 00:13:57 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!mcsun!sunic!news.lth.se!dag
From: dag@bellman.control.lth.se (Dag Bruck)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Dec9.075125.22405@lth.se>
Sender: news@lth.se
Organization: Department of Automatic Control, Lund, Sweden
References: <1992Dec2.111003.23102@jyu.fi> <1992Dec2.205330.10372@meaddata.com> <1992Dec4.070720.13056@lth.se> <1992Dec07.222242.18703@microsoft.com> <1992Dec8.103218.27689@lth.se> <1992Dec8.173855.18153@meaddata.com>
Date: Wed, 9 Dec 1992 07:51:25 GMT
Lines: 51

In <comp.std.c++> ralpht@meaddata.com (Ralph W. Trickey) writes:
>In article <...>, dag@seldon.control.lth.se (Dag Bruck) writes:
>|> I would be perfectly happy with a simple work-around, like the one
>|> above.  If the standard guarantees that given two pointers of the same
>|> type "p" and "q",
>|> 
>|> 	p != q  <=>  long(p) > long(q)  |  long(p) < long(q)
>
>..... It is usually easy to convert
>between pointers and memory addresses for a specific case, but that
>conversion should be implementation dependent. 

I repeat again: the result of the comparison may be implementation
dependent, all I want is that it exists.

>Attempting to require this for the general case becomes very
>complicated. How is the null pointer handled? Is it less than all
>other pointers, or is that implementation dependent, or what?

Yes. Implementation dependednt is fine with me.

> How is
>shared memory handled, if I have 2 pointers that are pointing to
>different addresses, but are pointing to the same object, must they
>compare equal?

As far as I can tell, C/C++ does not cater for shared memory anyway.

> What about future hardware that will keep reference
>counts, and merge/split objects as required.

That is not an issue.  If you have a C pointer to some object, the
pointer can never change because of something the hardware does to the
object.

>I like thing the way they are. I believe the C standard, and probably
>the C++ standard clearly states that the result of comparing 2
>pointers that are not pointing to the same array is undefined. If you
>are going to write hacks, don't expect them to be portable.

I argued that it should become defined, in order to facilitate the
writing of data structures in a portable way.  It is not a hack if the
standard specifies some behaviour, for example that

	p != q   <=>   p < q   |   p > q

for all pointers.  I'm not asking for a particular ordering, just an
implementation defined behaviour that meets the equivalence above.


			-- Dag