🚀 go-pugleaf

We seem to be arguing as much about the meaning of terms
and the model that should be used to define the semantics of C++
as we are about what the semantics are or should be.  I don't
think this is a fruitful discussion, so I'm going to take a different
tack and present my point of view solely in terms of code.

	struct X { int i ; } ;
	struct D : public X {
		X xInD ;
	} ;

	void set(X* p, int n) { p->i = n ; }

	void f() {
	    D d ;
	    X* p1 = &d;
	    X* p2 = &d.xInD ;
	    set(p1, 1) ;
	    set(p2, 2) ;
	    d.i ; // must be 1 
	    d.xInD.i ; // must be 2 
	    p1 == p2 ; // ????
        }


I'm not sure I can prove the two assertions (d.i is 1 and d.xInD.i is 2)
from the ARM.  I know I can't do it without using phrases (like
distinct object) that I'm trying to avoid in this post.  But I hope
there is no doubt about the assertions.

The rest of this posting is my opinion about how C++ ought to
be defined (by x3j16/wg21).

I believe that p1==p2 ought to be false (i.e. 0).  I'm not sure
I can prove it from the ARM, but I have what I consider good
justification. Namely, the only way that "set" can operate properly
with regard to d.i and d.xInX.i is for there to be some difference in
the values of its first argument on the two calls. Whatever this difference
is, it ought to be reflected in the result of ==.  If words to force
that result aren't already in the working paper, then I support
a change to the working paper.  Otherwise == on pointers becomes
almost useless and we would have to invent something else
(a library function perhaps) to do a complete comparison of 
pointer values.  

If there are any implementations out there that for which p1==p2
might be true in the above example, I'd be interested in hearing
about them. 

I'm not going to propose any exact wording here or address the question
of whether words already exist in the ARM because any attempt would
drop me into the terminological tar pit.  But I will say that I don't
think those words should make a distinction between X's that have or
don't have data members, or virtuals, or pure virtuals or anything
else.

  -- Jerry Schwarz