🚀 go-pugleaf

In article <9300300.29900@mulga.cs.mu.OZ.AU> (Fergus James HENDERSON) 
writes:
> pkt@lpi.liant.com (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    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com