Re: Assignment operator

[Zoltan Kocsi <zoltan at bendor dot com dot au>]

Mike Stump writes:

 > I'd love to see the verbiage, if you have it, both your question, and
 > their answer.  I'd like to see who said it as well.

I have all that stuff.
In conformance to the Netiquette :-), I'll ask for their permission to
disclose their names and the full content of their replies. 
 
 > A flag could be added, though I'd rather fix the standards, and get C
 > and C++ to follow the same rule for the same reason.  We then take the

Unfortunatelly, I've been advised that the C9X standard ballot has
been closed and passed - no more fixing for a while. 

In addition, AFAIK there's a major difference between C and C++. 
In C++ the value of an assignment operator is an lvalue, in C it is 
not. Making it an lvalue in C would (I think) deviate from the
original C spirit even more and confuse more C programmers than 
ever. Making it an rvalue in C++ would probably cause a revolt in the 
C++ community.
 
 > hit, and fix the compiler once, with one semantic.  Until that is
 > done, this is going to be non-portable and programmers should stay
 > away from this construct.  
 
The problem is, that according to the current wording of the standard
IMHO *any* access to a volatile object is non-portable. (See my other 
post onto the list).
 
 > I don't think a flag is the best approach.  I am against having a flag
 > for this.

I do believe that it is the standard which is wrong. However, during
my quest, someone told me that changing the standard (or its ill
behaving interpretation) would wreck havoc in the C community.
He may have a point. 

In addition, I can imagine that just like I have arguments for the 
interpretation I (and according to my belief, the K&R books) prefer, 
one could come up with arguments for the re-fetch business. The flag, 
at least as a temporary measure, would give the peace of mind to those 
who are concerned either way, while not affecting the rest. 
While everyone is happy with the switch turned to their liking, a 
constructive discussion (which is free of anger casued by frustration 
from battling with the compiler) on fixing the standard could commence.

 > I am sorry our decision and wording was so lax.  I think in the next
 > round it should be fixed.  Be sure to petition ANSI/ISO to fix this
 > next time you have the opportunity.

I'll do my best :-)
 
Regards,

Zoltan