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

Text File | 1993-01-02 | 2.9 KB | 65 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!lpi!pkt
From: [e-mail] (Scott Turner)
Subject: Re: pointer comparisons
Message-ID: <[e-mail]>
Organization: Liant Software Corporation
Distribution: usa
Date: Sat, 2 Jan 1993 21:15:38 GMT
Lines: 54

In article <[e-mail]> (Fergus James HENDERSON)
writes:
> [e-mail] (Scott Turner) writes:
> > 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.

> > 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, [...]
>
> 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.

Yes, that's a relevant point.  But it does not mean that 1.3 restricts
the compiler's ability to optimize, because 5.3.2 already says that
sizeof yields a result of at least 1.  So I'll hold to my conclusion
that the above excerpt from 1.3 belongs in the C++ standard.

> However, the murkiness of the concepts involved in "object identity" appears
> to make it very difficult or impossible to provide such guarantees
[about pointer comparison].

On the contrary, this lengthy discussion has regularly debated how pointer
comparison should work in relation to whether the pointers refer to the
same object.  Despite murkiness in the ARM, our shared concept of object
identity has held up.  I can think of only one example in which there was
disagreement about object identity, and in that case it seemed to be
cleared up quickly.

> My own metaphysical perspective is that subobjects are
> by definition not objects in their own right

My perspective, that subobjects are objects, has stood up to 4 years of
working with the C++ reference manual and working paper.  It fits in better
with the common application of the prefix "sub".  For example, a subset is
so called not because it belongs to a set, but because it _is_ a set
subordinate to another set.  If a subset were not properly a set, then
it never would have been called a subset.  Likewise "subobject" would be
a poor term if it did not refer to an object.

Furthermore, the ARM calls subobjects objects.  Look toward the end of
10.1.1 (p. 206) "the same object representing the base class".
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    [phone]
UUCP: uunet!lpi!pkt                          Internet: [e-mail]