🚀 go-pugleaf

In article <1992Dec31.170223.21637@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|In article <1992Dec30.184614.5551@microsoft.com> (Jim Adcock) writes:
|> Can you define your terms for us?
|
|> "distinct objects" means what?
|It means the objects are not identical.  

Which only leaves the issue of object identity.

|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 

Lots of other things remain unclear.  If a definition or a new expressions
reserves the storage needed by an object, when and when not can other
objects use this storage? [this is a trick question ;-]

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

Can other objects occupy those bytes?

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

That depends on what exactly is meant by "two pointers to the same type,
which point to distinct objects of that type"

At the very least "same type" and "distinct objects" remain poorly defined
in this discussion.

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

As I understand it, base class subobjects are NOT objects, because
in the case of virtual bases this would violate the contiguous-bytes
rule.  Further it would violate the overlapping objects rule.  Also,
it would imply that deriving some class from some base class can cause
a change in behavior of an "object" of that base class, and such flies
in the face of reason [IMHO].  So I believe "base clas subobjects" are
simply distinct views on one object.  One object can have multiple
identities then, depending on how it is viewed -- as demonstrated in
my multiple-base example.