NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/cplus/1949

Text File | 1993-01-02 | 3.9 KB | 89 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 2 Jan 1993 13:30:07 GMT
Lines: 77

[e-mail] (Scott Turner) writes:

>(Jim Adcock) writes:
>> "distinct objects" means what?
>It means the objects are not identical.
>
>I was going to say that the standard for C++ needs to spell out what it
>means for object to be identical in a better way than just by
>     1. An object is a region of storage.
>     2. A definition or a new expression reserves the storage
>        needed by the object.
>These two rules leave things much more loose than necessary when objects
>require no storage.  But note that section 1.3 of the working paper
>(The C++ Memory Model) says:
>
>    The constructs in a C++ program create, refer to, access, and
>    manipulate objects in memory.  Each object (except bit-fields)
>    occupies one or more contiguous bytes.

Let me just interject: what is the motivation for the above (as opposed
to "... occupies zero or more contiguous bytes")?
It seems to me that it is there primarily as an attempt to ensure some
sort of guarantee about pointer comparisons. (Are there any other reasons?)
However, the murkiness of the concepts involved in "object identity" appears
to make it very difficult or impossible to provide such guarantees.

If indeed it is the case that the above wording has failed to achieve its
purpose, then there are strong efficiency arguments which suggest that it
should be modified.

>I missed this a while back when enumerating the features of the ARM and
>working paper which supported
>> The desired feature is:
>>     Two pointers to the same type, which point to distinct objects
>>     of that type, compare not equal.
>This excerpt from 1.3 gives the general rule I was seeking, because
>objects can be distinguished by the storage reserved for them.
>
>The excerpt may raise a few questions.
>
>    How much freedom does it leave a compiler to optimize away
>    an object's bytes (by application of the "as if" rule, etc.)?
>    I think a good deal of freedom, because the working paper
>    doesn't define the results if a program attempts to refer to
>    or manipulate the bytes of an object.

Perhaps, but
    "The _sizeof_ operator yields the size, in bytes, of its operand".
I think that it would be a very brave compiler-writer whose compiler
made it unreliable to write() an object and read() it in again, because
    read(fd, &object, sizeof object);
randomly trashes the bytes past the end of the object.

>    Does it govern base class subobjects?  As I understand it,
>    base class subobjects are objects, and hence are covered.

Is your understanding based on reading the working paper, or discussion with
members of the committee, or is it your personal judgement of the meaning
of "subobject"? My own metaphysical perspective is that subobjects are
by definition not objects in their own right - that's why virtual functions
work the way they do. If subobjects *were* objects, then there would be
no difference between private inheritance and membership. Thus my own
personal judgement would be that (presuming nothing else is to the contrary)
base class subobjects would not be covered.

>    Does it belong in the C++ standard?  I'd say yes, given that
>    compilers will for many practical purposes be able to
>    optimize away unneeded bytes.

I would be inclined to suspect that such opportunities would be
quite rare, given the restrictions mentioned above.

--
Fergus Henderson             [e-mail]
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!