🚀 go-pugleaf

In article 95Sep25110939@godzilla.EECS.Berkeley.EDU, matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:
>In article <MATT.95Sep25095657@physics2.Berkeley.EDU> rmartin@rcmcon.com (Robert Martin) writes:
>> 
>> e.g.  the following used to be legal, but now is illegal.
>> 
>> for (int i=0; i<100; i++)
>> {
>>   // expressions using i;
>> }
>> 
>> if (i == 100) // loop ran to end.
>
>That's right.  The change does break existing code.  In fact, I
>suspect that the change will break almost every nontrivial C++
>program.  (Except for programs that were written with this change in
>mind.)
> ...
>
>I still don't quite understand the politics behind the change.  The
>new rule is clearly an improvement, and I even think it's enough of an
>improvement so that breaking so many programs is an acceptable cost,
>but I hadn't expected anythig of the sort from the standards
>committee.  I'd thought they were much more conservative than that.

A concatenation of things led to the change.

1. The old rule wasn't a good one, and many people found that trying to 
make use of it was more trouble than it was worth. (Add or delete a
loop in a function and you can't re-use the index anyway, since it will
often be undefined or double-defined. It is simpler during program
development just to put the declaration outside the loop.)

2. The old rule didn't have a satisfactory handling of cases like this
	for(int i = 0; ... ; ... )
		for(int j = 0; ... ; ... )
			...;
What is the scope of 'j'? Add braces to the outer for loop and it is
clearly limited to that scope. Without the braces, it is confusing
no matter which way you decide it. The ARM didn't say what the scope was.

3. With the addition of dynamic_cast, it became particularly desirable
to have limited-scope variables defined in loop or selection statements:
	if( T* p = dynamic_cast<T*>(e) { ... }
	else if( U* p = dynamic_cast<U*>(e) { ... }
A for-loop variable should then also have limited scope. This was the
clincher.

---
Steve Clamage, stephen.clamage@eng.sun.com



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]