🚀 go-pugleaf

jss:
|> ||Does anything go for A's.  E.g.
|> ||
|> ||	void f() {
|> ||	    A a1, a2 ;  // can &a1==&a2 
|> ||	    ... ; 
|> ||        }
|> |

jimad:
|> Let me restate the question as an answer.
|> 
|> Does the ARM anywhere say that two pointers of the same type to two different 
|> objects of the same type not in the same array must compare not equal?  
|> 
|> If not then what does the ARM say of any such comparison?

As far as I can tell, except for the special cases enumerated in
5.9 and some hints about the behavior of new, the ARM 
never requires two pointers to compare unequal.  I believe this is 
an oversight and should be corrected in the standard when it emerges. 
I believe the intention has always been that distinct objects have
distinct addresses and I belive that the final standard should say so.

What should x3j16/wg21 do? One alternative would be to leave
the words unchanged.  (I think this is Jim's position,
but I'm not sure.)  This apparently allows &a1==&a2 in the above,
and in other cases as well.  If the committee does this, it
should do it explicitly after due consideration and not simply
allow the status quo to remain by default.

Another possibility which has been proposed here recently (sorry
I don't remember by whom)  is to add something like "two pointers to
T (where T is an object type) compare equal if and only if they point
to the same object".   This seems a useful rule to me.  Note that
it makes no distinctions between "empty" and "non-empty"  classes.
An alternative might be to apply this rule except for "empty"
classes.  
	
So there really several related questions about this example.

	A: Does the ARM currently require a1!=a2?  Apparently 
	   not, but I may have overlooked something.

	B: What do existing compilers do.   How common is the
	   code that might be affected if the compiler was
	   changed to do something else.  How much existing
           code currently assumes that a1!=a2.

	D: Should the standard when it emerges require a1!=a2.
	   I think yes, and am concerned with exactly how to
	   word this requirement.  There are many potential
	   examples and I would greatly prefer a general rule
	   to an enumeration of cases.

Knowing the answers to A and B for this and similar cases
might influence my opinion  on C, but I am not prepared in advance
to state a rule that would allow you to derive my opinion of C
from the answers to A and B.
 
   -- Jerry Schwarz