From -220231600448171028
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-12-04 17:22:21 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Dec4.093044.16823@jyu.fi>
Organization: University of Jyvaskyla, Finland
References: <1992Nov30.195202.14370@ucc.su.OZ.AU> <1992Dec1.072440.824@jyu.fi> <1992Dec02.212336.26703@microsoft.com>
Date: Fri, 4 Dec 1992 09:30:44 GMT
Lines: 86

In article <1992Dec02.212336.26703@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
>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:
>|> ...
>Such use is not uncommon practice, and as such is a very practical example.
> ...
>use of them.  You cannot gratuitously make changes to the base language
>now without darned good justification -- which YOU have not established.

I think the example showed extremely bad hacking style, depending critically
on the behaviour of one specific compiler, while the same thing could be achieved
in a fully standard and portable way with minimal if any performance penalty.
I don't think that the C++ community as a whole has an obligation to assure
the continued legality of such bags of dirty tricks.
-- In the last few years there _have_ been gratuitous changes in the language
that have made fully standard code illegal (or perhaps worse still, legal but
with changed behaviour).  An example is the change of the meaning of 'protected'.

>| ...
>You still seem to be confusing the issue of conforming programs verses 
>strictly conforming programs.  A conforming PC program can use large
> ...
>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.
                          ^^^^

Please don't mix up C into this, C++ _is_ a separate language.
(I don't know about the drafts of the ANSI committee, but at least the ARM does not
use any terminology like 'conforming' and 'strictly conforming'.)
So you say that most C++ compilers for the PC used to be more or less broken
(could not implement the full language), and programmers were therefore forced
to dirty tricks as work-arounds?  Could you finally give a short concrete code example?

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

Please calm down (your throat will get sore if you use so many exclamation signs)
and try not to confuse things.  C++ as a language does not directly support
an OODBMS.  C++ pointers are memory pointers, and object references within an OODBMS
are a different thing (you will need a stronger and cleaner concept of object
identity there anyway).  I'll try to explain:

As long as we have C++ objects, i.e. in memory, their addresses (or at least the
valid pointer values to access them) _must_ stay constant, because C++ has no
means to automatically track down and modify all pointers to an object.
If the contents of some object are copied to or from the DB, that does not
change or complicate the situation.  On the other hand, if some C++ object is deleted
after having been copied to the DB, and the DB object is later restored into memory,
it will be a _new_ C++ object.  Nobody in this thread has required that its address
should have any defined relationship to the address of the deleted object.

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

Sorry, but IMO it's you who have been furiously defending hacks, not I.
Perhaps there is this misunderstanding:  you think that the requirement
of total ordering for pointers implies a linear address model.
No, we don't require that the ordering should directly map into physical order,
it's just as fine if a pointer consists of base and segment and relocation and index
or whatever.  Punning would do, i.e. treating the pointer as if it were an integer value.
However, the ARM does not require implementations to provide an integral type
that is sufficient to store an arbitrary pointer.

One obvious case where a total order of pointers would be nice to depend on
are (large) collections of pointers -- I think Andrew Koenig mentioned this
many submissions ago.  With total order, you can organise such collections
e.g. so that binary search can be used, requiring O(log N) time;
otherwise you are stuck with linear search and O(N) time.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------