From -6800512982949520793
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-19 15:59:34 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Dec17.221057.10997@microsoft.com>
Date: 17 Dec 92 22:10:57 GMT
Organization: Microsoft Corporation
References: <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com> <1992Dec16.150144.6004@ucc.su.OZ.AU>
Lines: 55

In article <1992Dec16.150144.6004@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|In article <1992Dec14.225659.24225@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
|>I think some flavor of "ptrcmp" makes sense on those implementations that
|>support casting pointers to integrals and back, and probably doesn't make
|>sense on those implementations that don't support the pointer/integral casts.
|
|	Why not?

Because in the cases I can think of, if one fails to be reasonably implementable
on a given system, the other also fails to be reasonably implementable, and
since C already allows that systems NOT be required to support the
pointer/integral cast.

|>In either case, I would ask what kind of sense it makes to write a "standard"
|>that *requires* a certain behavior of *some* implementation but doesn't
|>*require* that behavior of *all* implementations?  How do you justify such
|>a dichotomy?
|
|	ptrcmp is standard, required function, it must yield a total
|	order.

I was referring to the pointer/integral cast.  It is not required of
all systems, only of some systems.  *Required* of *some* systems????
This certainly contradicts my expectations of what a "standard" means!

|	In that case it is implementable on all systems
|	where (opinion follows, please correct errors)
|
|	a) void* is big enough to hold all pointer types
This assumption is almost univerally violated.

|	b) conversions always pad systematically
|	c) bitwise comparison is done 
|	d) the bits of a pointer cannot be magically changed by the system
Violated  by real mode Windows, Violated by evacuating GC'ed machines.
Violated by at least one GC'ed C++ implementation. Violated by
at least some OODBMSs.

|	e) a pointer is implemented as an object in contiguous storage
Probably violated by some OODBMSs.

|	Certainly, (e) might cause problems on the 80x86 where part of the
|pointer is implicit and not physically stored. Does it *actually*
|cause this problem?

No because implied segments can be made specific.  Segments can
be moved on some systems however, implying an ordering that requires
the segment part will not remain consistent.  Within a segment however,
object orderings remain consistent.  Unless the PC is running a system
with GC and ptr tracing, such that objects are moved to be compacted.
Since such systems by a large margin have the best memory management
that I've seen, I think it would be a big mistake to preclude them 
for the kind of algorithm implemetation tricks you guys have been 
talking about -- especially since surrogates or similar approaches
can accomplish your goals about as well as the ptrcmp stuff.