From -2281444702509982354
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-03 02:23:41 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: <1992Dec02.212336.26703@microsoft.com>
Date: 02 Dec 92 21:23:36 GMT
Organization: Microsoft Corporation
References: <1992Nov27.091056.3895@jyu.fi> <1992Nov30.195202.14370@ucc.su.OZ.AU> <1992Dec1.072440.824@jyu.fi>
Lines: 64

In article <1992Dec1.072440.824@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
|In article <1992Nov30.195202.14370@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|>	On the 80x86 machines, with segmented architectures,
|>one might define == and != to comparte BOTH the offset and segment
|>(as required by the ARM and the extra rule you suggested ought to
|>have been in the ARM).

This is in fact common implementation.

|>	However, the < operator might be implemented to compare
|>ONLY the offset part. This is legal because it is 'implementation
|>defined'. One could create TWO arrays in different segments,
|>and use < to compare relative positions of pointers into
|>these different arrays.

Exactly.

|>This is not a very practical example, Jim can provide a better one
|>perhaps. 

Such use is not uncommon practice, and as such is a very practical example.
Again, we are not talking about breaking future programming efforts, we
are talking about NOT breaking existant programming efforts.  The argument
that "there are better ways to program these things" matters not a whit.
All that matters is that these things ARE legal and programmers DID make
use of them.  You cannot gratuitously make changes to the base language
now without darned good justification -- which YOU have not established.

|I still cannot believe Jim Adcock's claim that this would affect "tons of useful
|software".  In what circumstances would one normally be interested about the segments
|in which the objects lie?  The above idiom does not help to test whether the pointers
|point into different _arrays_, since there can be more than one array in each segment.

You still seem to be confusing the issue of conforming programs verses 
strictly conforming programs.  A conforming PC program can use large
model pointers into different segments, and then make use of that fact
that pointer < > comparisons are only performed on the offset parts 
in order to use those pointers as if they are offsets.  Such usages are
common because only recently have PC compilers given explicit support
for segment and offset variables.  Prior to these language extensions, 
such comparisons HAD to be done by hack because their was no language
support for them.  Now you proprse to require C++ implementaions break
these existant conforming C programs.

Further, you still have not touched on the issue of C++ OODBMS and the
fact that you guys proposal of total ordering would require OODBMSs to 
maintain a total ordering on objects on the database even through
a store/query/restore to memory.  Seems an unnecessary and painful restriction
on OODBMSs that a query/restore to memory cannot order the objects in
back into memory in the order the query found those objects.  Surely
you jest!?  Maintain a total ordering over a OODBMS!!??

Again, seems clear to me that using a total ordering is simply a
un*x-memory model hack, and should be treated as such.  If *you* want
to use such a hack, then use it.  Don't require everyone else in the
world to support your hack.  PCs, OODBMSs, Lisp-machine, etc, are all examples 
that don't follow the un*x memory model, are still very interesting for 
C++ work [with 100,000s of C++ compilers sold], and which shouldn't be 
gratuitously excluded from the C++ world.  Further, you are ignoring the 
emerging crop of RISC machines which are themselves segmented architectures, 
of the form 16:32 and/or 32:32.  

What you propose simply doesn't scale.