[C/C++] New ISO 'for' loop scoping?

[NeBuR]

Hello, again  .

I've found a problem with the for loop. Look at this code:

Code Select Expand


for (int counter = min1; counter < max1; counter++)
{
   ...   // Arbitrary code.
}

for (counter = min2; counter < max2; counter++)
{
   ...   // More arbitrary code.
}


Integer limit values of looping (min1, max1, min2 and max2) doesn't matter at all, while the problem is related to the 'counter' variable scope. I've verified that this code compiles without errors in M$ Visual C++ 6.0. But recently, trying to move an application to a UNIX enviroment, I've found the next error message while compiling it with GNU gcc 3.0.1:

Name lookup of `counter' changed for new ISO `for' scoping.
Using obsolete binding at `counter'.

Then I've tried the code with M$ Visual Studio .NET, and it accepts with no errors the last code fragment, as well as the next:

Code Select Expand


for (int counter = min1; counter < max1; counter++)
{
   ...   // Arbitrary code.
}

for (int counter = min2; counter < max2; counter++)
{
   ...   // More arbitrary code.
}


So my question is this: has the for loop been modified (by ISO) to consider variables declared in its header belonging to its internal scope?

[Zakath]

As far as I know, this has always been the case. I frequently use the same variable name (usually "i") for all my for loops at the same scope, redeclaring it each time.

But yes, ISO C++ states that you should not rely on a variable declared in a for loop being available after the loop terminates.

[iago]

I agree with Zak.  There's probably an option somewhere in VS to enable warnings for that, but it shouldn't even compile :/

[Raven]

It's not a problem at all. A variable declared as part of the loop will remain local for only that loop. This can easily be avoided by declaring your counter variable outside the loop itself.

[Kp]

As far as I know, this has always been the case.

No.  It used to be the way that VC accepts: treating a variable declared in the pre-loop component as declared immediately prior to the for, and thus valid for the remainder of the function.  The standard changed and VC was never updated to become compliant again.  gcc is compliant, but also permits you to do it the old way (and gives the warning Nebur noted).  Strictly speaking, VC is noncompliant with respect to the standard when it silently accepts code which fails to redeclare the variable.  Given that the noncompliance has propagated forward into VC7, I rather doubt they're going to fix it though.

[Yoni]

Given that the noncompliance has propagated forward into VC7, I rather doubt they're going to fix it though.

Actually, they fixed it in VC7, but the fix is disabled by default so that code that compiles under VC6 would work with no changes.



The fix is enabled either by selecting "Yes" for the highlighted option in the above screenshot (equivalent to "/Zc:forScope" for cl.exe), or by selecting "Yes" for "Disable Language Extensions" in the above screenshot (equivalent to "/Za" for cl.exe, the 'a' stands for ANSI).

[Kp]

Actually, they fixed it in VC7, but the fix is disabled by default so that code that compiles under VC6 would work with no changes.

Interesting.  Is there any way to change the default, so that all subsequently created projects will default to conformance rather than nonconformance?

[Yoni]

Not that I know of, should be worth looking into sometime though. (If you can do that, you can probably change other defaults to something less annoying than the default defaults - some of which I always change...)

[iago]

Doesn't VC7 have support for Template projects?  If it does, it might be the easiest way to create a template, set the options the way you like it, and go from there.

[Skywing]

Doesn't VC7 have support for Template projects?  If it does, it might be the easiest way to create a template, set the options the way you like it, and go from there.

Yes, it does.  Unfortunately, you seem to have to write the templates in JScript.

For loop scoping is hardly "new".