From -3759520009640771281
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-16 20:54:57 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <9235215.11144@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
References: <1992Dec8.173855.18153@meaddata.com> <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.225659.24225@microsoft.com>
Date: Thu, 17 Dec 1992 04:43:04 GMT
Lines: 42

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.
>
>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 intended to be universal, ie. required of *all* implementations.

>Such would be the proper designation, IMHO, for both the bidi pointer/integral
>cast, and for the proposed "ptrcmp" macro.  Then, on Lisp machines, or 
>C++ OODBMS's or whatever systens would find the total ordering 
>practically unsupportable in their environment [...]

Why would ptrcmp() be practically unsupportable in these environments?
OODBMS's maintain an object identity for each object, so it should be
possible to base a total ordering on this object identity. I don't see
the problems. What makes it difficult for Lisp machines? Are efficient
BTrees and such-like genuinely impossible on such machines?

>In any case, "ptrcmp" would be a misnomer, because what is being compared
>is *not* pointers, but rather the underlying *assumed* implementation of 
>pointers using machine addresses.  The correct name might be something like 
>"addrcmp" then, so as to not further confuse programmers on the difference
>between language and implementation.

The function should be named after its interface, not its implementation.
The function takes two (void *) _pointers_, and returns an integer which
is meant to be a comparison of those pointers according to some total
ordering.
Whether it is implemented by comparing addresses or by sending mail to
the Usenet Oracle and waiting for a reply is not relevant.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!