In article <MATT.95Sep25095657@physics2.Berkeley.EDU> rmartin@rcmcon.com (Robert Martin) writes:

> Do I have this right?  If so, doesn't this break a lot of old C++
> programs that depended upon variables declared in the 'for' statement
> being local to the enclosing scope.
>
> 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.)

Just about the only good news is that most programs will break
noisily: it's only when you're already playing dangerous games with
variables of the same name in different scopes that a legal program
that does one thing will turn into a legal program that does something
else.  The other piece of good news is that this is a simple enough
change that programs can probably be converted by a simple mechanical
translator.  (Has anyone written one yet?)  I'm sure, also, that all
major compiler vendors will provide backward compatibility switches.

The latest version of gcc implements the new rule about the scope of
variables declared in for loops.  You can try your code out using
gcc 2.7.0 to find out just how many things break.

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.
--
  Matt Austern                             He showed his lower teeth.  "We
  matt@physics.berkeley.edu                all have flaws," he said, "and
  http://dogbert.lbl.gov/~matt             mine is being wicked."
---
[ 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. ]

I wrote:
>surprises that used to be legal (e.g. you could have the lifetime and
>scope of an object not end at the same time, and then there was some
>weirdness introduced by the RTTI rules).

That last phrase is shoddy writing.  Instead of the sloppy (and wrong) "some
weirdness introduced", Steve said much more clearly:

Steve Clamage wrote:
>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.

Mea culpa!

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ 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. ]

In article <MATT.95Sep25095657@physics2.berkeley.edu> you write:
>Do I have this right?  If so, doesn't this break a lot of old C++
>programs that depended upon variables declared in the 'for' statement
>being local to the enclosing scope.

Yes, it sure does.  However this was first talked about back when the
ARM was written.  Good compilers will let you do both.  Here's what
gcc-2.7.1 will do for your code snippet -

(Default options)
xx.cc: In function `int main()':
xx.cc:6: warning: name lookup of `i' changed for new ANSI `for' scoping
xx.cc:1: warning:   using obsolete binding at `i'

(-ansi -pedantic -ffor-scope)
xx.cc: In function `int main()':
xx.cc:6: `i' undeclared (first use this function)
xx.cc:6: (Each undeclared identifier is reported only once
xx.cc:6: for each function it appears in.)

Regards,
 Rohan
--
----------------------------------------------------------------------------
rjl@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard            | writing tool.  Yours for just $19.95; and if you
+61-2-367-4555          | call now you'll get a free set of steak knives ...
---
[ 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. ]

rmartin@rcmcon.com (Robert Martin) wrote:
>
>In reading the WP I see that the scope of variables declared in 'for'
>statements is now identical with the scope of variables declared in
>'if' and 'while' statements.  i.e. any variable declared in a 'for',
>'if' or 'while' statement is local to the statement, and to the
>controlled statement, but not to the enclosing scope.


   In fact, the WP is not clear, and is probably inconsistent
about all these cases. It isn't clear which scope
such a declared variable is in. Consider:

   if(int i=0)int i;      //#1 ambiguous wording in the WP
   if(int i=0){ int i; }  //#2 ambiguous wording in the WP
   if(int i=0){{int i; }} // definitely legal


The WP mumbles incomprehensibly about not being allowed to
redeclare the control variable in the outer scope of the
controlled statement. This is not supported by the grammar:

  if-statement:
    "if" "(" cond ")" statement

in which statement can be a compound statement. By this grammar
#2 cannot be sensibly disallowed. Instead one would need
an extra production:

     "if" "(" cond ")" "{" statement-list "}"

in which the {} extend the scope of the condition rather
than introducing a new scope NESTED in the scope of the
condition.






--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au



[ 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. ]