🚀 go-pugleaf

In article <1993Jan05.003819.12515@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> 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.

Which is where I wish to leave the issue, willing to trust for the present
that objects which I wish distinct will be distinct.  This trust rests on

      1. The status of distinct objects as objects.

      2. The guarantee of 1.3 that an object occupies at least 1 byte
         of storage.

      3. The implementation's duty to reserve storage for objects.

If anyone can think of an example in which I am likely to be diappointed
and end up surprised with indistinct objects, I'd be grateful to see it.  
(Implementations which don't do their duty aren't necessarily a surprise.)

> 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 ;-]

I was responding to clarify a possible feature of pointer comparison.
To clarify everything is beyond me.

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

Yes.  An _other_ object is distinct, not identical to the object with which
it shares storage.  For example, given
	int x[9];
then the bytes occupied by the objects x and x[2] overlap.

> |	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 [...]
> Further it would violate the overlapping objects rule.  

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

If some class declares a virtual function, it's asking to be changeable.
--
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