🚀 go-pugleaf

In article <1992Dec24.011254.1982@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:
> What needs to be made clear includes what is meant by "point to the
> same object."  As in my example the pointers *do* point to the same object,
> and they do compare equal.  It's just that one pointer refers to an
> enclosing object, and one pointer the enclosed object.  Same object,
> just not identically the same object.  

This explanation of your example could be more clear.  
If one pointer refers to an an enclosing object, and another to an enclosed
object, that sounds like different objects to me.

I've been advocating a strong relationship between pointer comparison
and identity of the objects pointed to.  It occurs to me that pointers
of type void* do not fit into this framework in C++, and not really in
C either.  If we want a guarantee that
	(void*)&a == (void*)&a
then how would the standard specify it?

> Ultimately, I do not believe worrying about these pointer "details" 
> is very important unless one first decides what properties of object
> identity C++ objects must have and why.  The current permission of
> C++ compilers to create temporaries at will kind of blows object identity
> out of the water.  Why worry about pointer equality, then?

I'd be happy to have a more precise description of C++ objects and their
identity, but temporaries are not much of a problem.
Programs rely on object identity via pointers, references, and lvalues.
12.2 of the ARM and working paper sanctions the introduction of temporaries,
but no one interprets this as affecting pointer, reference, and lvalue
expressions.  
--
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