NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/std/cplus/1806

Text File | 1992-12-16 | 2.8 KB | 63 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 16 Dec 1992 15:52:31 GMT
Lines: 50

In article <[e-mail]> [e-mail] (Jim Adcock) writes:
>
>|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.
>
>Wrongo.  Again you confuse language and implementation.  On the contrary,
>I've written an internal implementation of C++ that does have the means to
>automatically track down and modify all pointers to an object.  There
>are other systems that do this kind of thing too.  Such as early versions of
>Windows.

    Certainly, such an internal tracking mechanism (Jim, you really
actually wrote such a routine??) is legal with the
current definition of C++ provided object identity is preserved.

    Clearly retaining a total order over such a routine,
especially an incremental one, would be a heavy constraint
on the sort of algorithm you would be allowed to implement.

    Even restricting the intent of such a routine
to say, compaction: At the moment the only requirement would be that all the
pointers to a moved object be changed in one increment.
(So equality tests continue to work)

You might reorder all the objects in memory. Preserving a total order
in an incremental system might be suboptimal. So that requirement
would break your system OR force you to make it suboptimal.
(Where suboptimal might include abandoning it altogether .. and then
maybe the program wont run at all .. totally breaking the program)

    So there is a tradeoff---a class of code using Jims
sneaky tricks breaks, or an as yet non-existant class
of code depending on total order breaks.

    Perhaps unfortunately such a tradeoff can only be resolved
one way by the committee---namely that of requiring
compatibility with existing code. Because no one can be
sure Jim is the only one doing sneaky tricks. Or there arent
other types of legal sneaky tricks.

(** 'sneaky tricks' is not meant to be anything than the first words
that popped into my head.)


--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------