From 105959507970984383
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-06 11:45:56 PST
Path: sparky!uunet!enterpoop.mit.edu!eru.mt.luth.se!hagbard!loglule!jbn
From: jbn@lulea.trab.se (Johan Bengtsson)
Newsgroups: comp.std.c++
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <5317@holden.lulea.trab.se>
Date: 6 Dec 92 18:58:19 GMT
References: <1992Dec05.012131.14948@microsoft.com>
Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
Lines: 65
X-Newsreader: Tin 1.1 PL4

jimad@microsoft.com (Jim Adcock) writes:
: In article <5305@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
: |Not being pro total ordering, allow me to point out that compilers
: |for segmented architectures of course would keep compatibility switches
: |to disable the total ordering property, gaining some speed.  Also,
: |customers of those programs will tend to buy faster computers over time,
: |so the specifications can still be met, only with more modern hardware.
: |I see no real problem here.
: 
: Actually it would be such a big lose on PC architectures that I would
: suspect that compilers for such would ship with total ordering off
: by default, and with total ordering only enabled in strict compatibility
: mode.

That would make new customers who have read about the standard kind of
unhappy when their programs mysteriously crash.  Anyway, I made a simple
test, running a pointer through char arrays of size 1000 a large number
of times, using

ptr1 < ptr2
and
(long)ptr1 < (long)ptr2

which happens to be the way to get a total ordering with Microsoft C 6.00,
with 286 code generation.  Total ordering made the program take about 33%
longer.  I would suspect that a compiler that generates 386 code would
have zero overhead for total ordering (anyone confirm?).

This is what I did (I don't have the complete program handy):

char* ptr, start, stop;
//...
ptr = start;
stop = start + 1000;
while ( ptr < stop ) {  // or (long)ptr < (long)stop
   ++ptr;
}

I would excpect such tight loops to be rare in programs, and
a #pragma(no_total_order), or a compiler switch  could be provided
to get speed in those hot spots.

However, I agree that the benefit of total ordering is not great enough
to impose even this small performance penalty, since there is a simple
technique that can be used for code that needs total pointer order:

inline int ptr_less( void* p1, void* p2 ) {
   return ( sizeof(long)==sizeof(p1) ?
            ((long)p1 < (long)p2) :
            (p1 < p2)
          );
}

This definitions works for the C/C++ implementations that I
have experience with (PC and UNIX).  I'm sure there are or will
be implementations for which the above function does not work,
but that can be handled by machine/compiler specific code.

Anyone know of machines/compilers for which the above function does not work?

-- 
--------------------------------------------------------------------------
| Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
| Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
--------------------------------------------------------------------------