From -5229655573310391401
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-09 04:48:14 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: <9234423.15066@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU
Organization: Computer Science, University of Melbourne, Australia
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>
Date: Wed, 9 Dec 1992 12:41:49 GMT
Lines: 50

dag@seldon.control.lth.se (Dag Bruck) writes:

>In <comp.std.c++> jimad@microsoft.com (Jim Adcock) writes:
>>
>>If you want to compare addresses, the following works on all computers
>>and compilers I've ever had to deal with:
>>
>>if (((long)ptr_a) > ((long)ptr_b))
>>	blah();
>
>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)
>
>I assume this is not the case now, but if a trivial change in the
>standard document would give us this guarantee, the problem is solved
>and we need not discuss it anymore.
>
>If there are any problems, for example, if all significant bits of the
>pointers will not fit into a long integer, I think we're back to
>square one again and have to define "operator<" for pointers.  The
>alternative is of course to dismiss the idea as not worth the trouble.

There is exactly that problem (that pointers may not fit in long ints),
but we don't have to go back to square one.

What I propose is that we define a *standard library function* which computes
a total ordering on pointers. This would work on virtually any system
without imposing undue constraints on the implementation. Programs written
for Intel architectures would not slow down, but the template collection class
writers get their total ordering. It should make everyone happy! :-)

int compare_pointers(const void *, const void *);
    /* Returns negative, zero, or positive in the same manner as strcmp().
       Perhaps in the interests of tradition and unreadability it should
       be called ptrcmp() instead of compare_pointers() :-) */

This is basically the same as Alan Braggin's suggestion to use
int Comparable::operator < (const Comparable &), but it is important
that it be a standard library function, since it may have to be
implemented in assembly. It is hardly a burden on implementors:
for the vast majority of machines, it should be just a one-liner.

-- 
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!


