comeau@panix.com (Greg Comeau) writes:

|>  In article <rf5g20f6qaw.fsf@vx.cit.alcatel.fr> James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>  >I might add that I really doubt that there will be any case in my code
|>  >of the silent change occuring, so even if the compiler did warn, I
|>  >probably won't see it.
|>
|>  I don't follow what you won't see.

There won't be any silent changes in my code, so I won't see a warning,
even if the compiler generates one.  (I generally use very short
variable names, like i and j, for loop control variables, and don't use
such short names in any other case.)

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

comeau@panix.com (Greg Comeau) writes:

    [Considering the new for scope...]
|>  >In short, what you want is already required (to the extent that a
|>  >draft of a standard can require anything) and it's basically just a
|>  >matter of time until you can actually plan on using it.
|>
|>  It's not a matter of just planning.  That is, some compilers do support it
|>  now, so it's a matter of actually getting those compilers or not.

Not all of us are free to use whatever compiler we want:-).  In
practice, the intermediate solution is to write code that works either
way: don't count on a variable declared in the for being available
outside of the loop, but don't count on being able to declare a variable
with the same name later, either.

Concerning compilers, it would be nice if the compiler had an option
which would enforce the above rule (by generating a warning when it is
violated).  It would also be *VERY* nice if the compiler would generate
a warning anytime the program would be legal under both rules, but with
different semantics.  (This occurs when there is a variable in an outer
scope with the same name as the variable declared in the for, and one
uses the variable declared in the for after the loop.  With reasonable
variable names, the case should be very rare, but it will be a real pain
to find when it does occur.)

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5abicd$jdu@erawan.cognex.com>, Michael R Cook <mcook@cognex.com> writes:
|> Your compiler seems to be out of date.  Apparently there was some ambiguity
|> about the scope of `i' at one point, but the latest draft of the standard is
|> unambiguous:
|>
|> |  6.5.3  The for statement                                    [stmt.for]
|> |...
|> |3 If  the  for-init-statement is a declaration, the scope of the name(s)
|> |  declared extends to the end of the for-statement.  [Example:
|> |          int i = 42;
|> |          int a[10];
|> |
|> |          for (int i = 0; i < 10; i++)
|> |                  a[i] = i;
|> |
|> |          int j = i;        // j = 42
|> |   --end example]

I wouldn't say the compiler is "out-of-date".  At what point should you
adopt stuff from the new standard?  What happens to code that counts on
"old" behavior?  I work on a compiler that does some new stuff and some
old and there are users who both want it changed and left alone.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
  Home page:  http://members.aol.com/BillSeurer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5agi9d$n06@panther.rmplc.co.uk> duncan@rcp.co.uk (Duncan Booth) writes:
>In article <01bbf694$dd2b0f40$904697c2@fvl.iaehv.nl>, "F. van Leeuwen" <fvl@iaehv.nl> wrote:
>>If I want to program a loop, I can comfortably declare
>>the loop counter inside the 'for', e.g.
>>
>>for (int i=0; i<LOOPCOUNT; i++) {
>>  ...
>>}
>>
>>But the scope of 'i' reaches somehow outside the loop,
>>because a second loop cannot have the same declaration.
>>I would then have to declare 'int i' outside the first
>>'for' again, or I would have to choose a different name
>>for the second counter.
>>
>>If the scope of variables declared inside such statements
>>as 'for', could be as if declared inside the compound
>>statement, it would solve this.
>>
>>Frank van Leeuwen.
>
>This feature is already in the standard. In the meantime, if your compiler
>does not yet support it, you can get the same effect with the following macro:
>
>        #define for if(0) ; else for

While yelling at your vendor, of course ;-)

>No need to change your source code, the only effect will be that the scope of
>'i' is restricted to the inside of the for loop. Once your compiler is
>upgraded you can remove the macro (but the code will work correctly even if
>you dont).
>
>There is one slight problem with this macro --- any decent compiler is likely
>to grumble about the constant conditional.

There is also the "problem" that this change is as silently robotic
at the macro level as you make it, but not at the transition level
so to speak.  That is to say, two situations arise with "old" code
under the new rules:
(1) The identifier is used after of the loop and so has no declaration.
    This implies an error and so a code rewrite of the for statement is
    in order.
(2) There is an identifier of the same name in an outer visibile scope.
    It is used.  This is not an error but a gotcha of the old code
    under the new rules.  This becomes a so-called `quality of implementation'
    issue for the compiler.  For instance, Comeau C++ issues a warning
   in such a situation.

Although I suspect one can be careless with new code, or not know
the new rules, and so still run into these, it is otherwise not a problem
with new code.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> "JK" == James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

 JK> Concerning compilers, it would be nice if the compiler had an option
 JK> which would enforce the above rule (by generating a warning when it is
 JK> violated).  It would also be *VERY* nice if the compiler would generate
 JK> a warning anytime the program would be legal under both rules, but with
 JK> different semantics.

FWIW, gcc can generate such warnings.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5ah9pl$q7c@news.rchland.ibm.com> "Bill Seurer" <seurer@VNET.IBM.COM> writes:
>In article <5abicd$jdu@erawan.cognex.com>, Michael R Cook <mcook@cognex.com> writes:
>|> Your compiler seems to be out of date.  Apparently there was some ambiguity
>|> about the scope of `i' at one point, but the latest draft of the standard is
>|> unambiguous:
>|>
>|> |  6.5.3  The for statement                                    [stmt.for]
>|> |...
>|> |3 If  the  for-init-statement is a declaration, the scope of the name(s)
>|> |  declared extends to the end of the for-statement.  [Example:
>|> |          int i = 42;
>|> |          int a[10];
>|> |
>|> |          for (int i = 0; i < 10; i++)
>|> |                  a[i] = i;
>|> |
>|> |          int j = i;        // j = 42
>|> |   --end example]
>
>I wouldn't say the compiler is "out-of-date".  At what point should you
>adopt stuff from the new standard?  What happens to code that counts on
>"old" behavior?  I work on a compiler that does some new stuff and some
>old and there are users who both want it changed and left alone.

Even though this particular change is starting to show its age and can be
classified as one of the more simple ones to implement, I think you raise
an important point.  We need to be on both sides of the fence wrt the
standard .  This doesn't negate that you shouldn't
get on your vendors case though.  Similarly, when said et al is
implemented, vendors should recognize that a transition period needs
to be available in many shops and so should provide options for such
opportunities.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5rak35dwh.fsf@vx.cit.alcatel.fr> James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
>comeau@panix.com (Greg Comeau) writes:
>
>    [Considering the new for scope...]
>|>  >In short, what you want is already required (to the extent that a
>|>  >draft of a standard can require anything) and it's basically just a
>|>  >matter of time until you can actually plan on using it.
>|>
>|>  It's not a matter of just planning.  That is, some compilers do support it
>|>  now, so it's a matter of actually getting those compilers or not.
>
>Not all of us are free to use whatever compiler we want:-).

Er, well... ;-)

Seriously though, I did not intent to imply that people could.
I was simply responding to that I thought (perhaps I misunderstood)
it was said that people could only plan for it, and I feel that is
not the case.

>practice, the intermediate solution is to write code that works either
>In way: don't count on a variable declared in the for being available
>outside of the loop, but don't count on being able to declare a variable
>with the same name later, either.

Yes.  Of course, in a way, that was always an option, and some may
argue the right way to do it anyway.

>Concerning compilers, it would be nice if the compiler had an option
>which would enforce the above rule (by generating a warning when it is
>violated).  It would also be *VERY* nice if the compiler would generate
>a warning anytime the program would be legal under both rules, but with
>different semantics.  (This occurs when there is a variable in an outer
>scope with the same name as the variable declared in the for, and one
>uses the variable declared in the for after the loop.  With reasonable
>variable names, the case should be very rare, but it will be a real pain
>to find when it does occur.)

Comeau C++ 4.0 Pre-Release does just that. ;-)  I would imagine others
supporting this feature do too, but you seem to imply otherwise???

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5ajt3o$6ul@panix.com>, comeau@panix.com says...

[ talking about scope of variables declared in for loops ]

> Seriously though, I did not intent to imply that people could.
> I was simply responding to that I thought (perhaps I misunderstood)
> it was said that people could only plan for it, and I feel that is
> not the case.

I specifically said that some compilers already implement it. However,
it was apparent from the original question that he was using a
compiler that didn't support the new scoping rule yet.  Depending on
circumstances, he might be able to switch to a compiler that
implements the new scoping rules, but IMO, by itself that would be
poor justification for switching compilers.

[ compilers including warnings about the change in scope ]

> Comeau C++ 4.0 Pre-Release does just that. ;-)  I would imagine
> others supporting this feature do too, but you seem to imply
> otherwise???

All the compilers I've used that support the new scoping include
warnings about it, but that's only a few compilers.

[ changing the subject slightly, and attempting to get back toward
topicality ]

What I've always wondered is why the scoping was EVER the way it was
originally defined.  I suppose from a theoretical viewpoint, the for
loop is outside the statement it controls, but the original definition
still never seemed to me to make much sense at all.


--
    Later,
    Jerry.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

comeau@panix.com (Greg Comeau) writes:

|>  >practice, the intermediate solution is to write code that works either
|>  >In way: don't count on a variable declared in the for being available
|>  >outside of the loop, but don't count on being able to declare a variable
|>  >with the same name later, either.
|>
|>  Yes.  Of course, in a way, that was always an option, and some may
|>  argue the right way to do it anyway.

If the code must compile and work with a variety of compilers, it is the
only solution which will work.  Some may argue that this is as good a
definition as any of "the right way to do it":-).

|>  >Concerning compilers, it would be nice if the compiler had an option
|>  >which would enforce the above rule (by generating a warning when it is
|>  >violated).  It would also be *VERY* nice if the compiler would generate
|>  >a warning anytime the program would be legal under both rules, but with
|>  >different semantics.  (This occurs when there is a variable in an outer
|>  >scope with the same name as the variable declared in the for, and one
|>  >uses the variable declared in the for after the loop.  With reasonable
|>  >variable names, the case should be very rare, but it will be a real pain
|>  >to find when it does occur.)
|>
|>  Comeau C++ 4.0 Pre-Release does just that. ;-)  I would imagine others
|>  supporting this feature do too, but you seem to imply otherwise???

I've very little experience with any compiler which supports the new
scope, so I really don't know how other compilers will handle this.  I
do know that there are a lot of changes for compiler writers to
integrate, and that it is easy to forget little details like generating
such warnings in the lot of work to be done.

I might add that I really doubt that there will be any case in my code
of the silent change occuring, so even if the compiler did warn, I
probably won't see it.

I might add that I very much like the way g++ handles the normal case:
if the program is illegal under the new rules, but would have been legal
if the variable declared in the for loop were still in scope, g++
applies the old scope rule, with a warning.  (I do hope that there is an
option to turn this off, however, and to use strictly one rule or the
other.  I've not had time to check the documentation to be sure,
however.)

--
James Kanze         home:     kanze@gabi-soft.fr        +33 (0)3 88 14 49 00
                    office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
       -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <MPLANET.32ceb9a3jcoffin989b1c@news.rmi.net> jcoffin@taeus.com (Jerry Coffin) writes:
>In article <5ajt3o$6ul@panix.com>, comeau@panix.com says...
>
>[ talking about scope of variables declared in for loops ]
>
>> Seriously though, I did not intent to imply that people could.
>> I was simply responding to that I thought (perhaps I misunderstood)
>> it was said that people could only plan for it, and I feel that is
>> not the case.
>
>I specifically said that some compilers already implement it. However,
>it was apparent from the original question that he was using a
>compiler that didn't support the new scoping rule yet.  Depending on
>circumstances, he might be able to switch to a compiler that
>implements the new scoping rules, but IMO, by itself that would be
>poor justification for switching compilers.
>
>[ compilers including warnings about the change in scope ]
>
>> Comeau C++ 4.0 Pre-Release does just that. ;-)  I would imagine
>> others supporting this feature do too, but you seem to imply
>> otherwise???
>
>All the compilers I've used that support the new scoping include
>warnings about it, but that's only a few compilers.
>
>[ changing the subject slightly, and attempting to get back toward
>topicality ]
>
>What I've always wondered is why the scoping was EVER the way it was
>originally defined.  I suppose from a theoretical viewpoint, the for
>loop is outside the statement it controls, but the original definition
>still never seemed to me to make much sense at all.

This one (IMO) is a no-win situation.
That is, the most compelling reason seems to be that you could
check after the loop in case it break'd out.
Depending upon how you look at it, both ways make sense and no sense.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <MPLANET.32ceb9a3jcoffin989b1c@news.rmi.net>, jcoffin@taeus.com

[snip]
>
> What I've always wondered is why the scoping was EVER the way it was
> originally defined.  I suppose from a theoretical viewpoint, the for
> loop is outside the statement it controls, but the original definition
> still never seemed to me to make much sense at all.
>

Although the capability can be provided easily in code, the original scope
rule allowed testing how far the loop went before exiting with a break.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5g20f6qaw.fsf@vx.cit.alcatel.fr> James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
>comeau@panix.com (Greg Comeau) writes:
>
>|>  >Concerning compilers, it would be nice if the compiler had an option
>|>  >which would enforce the above rule (by generating a warning when it is
>|>  >violated).  It would also be *VERY* nice if the compiler would generate
>|>  >a warning anytime the program would be legal under both rules, but with
>|>  >different semantics.  (This occurs when there is a variable in an outer
>|>  >scope with the same name as the variable declared in the for, and one
>|>  >uses the variable declared in the for after the loop.  With reasonable
>|>  >variable names, the case should be very rare, but it will be a real pain
>|>  >to find when it does occur.)
>|>
>|>  Comeau C++ 4.0 Pre-Release does just that. ;-)  I would imagine others
>|>  supporting this feature do too, but you seem to imply otherwise???
>
>I've very little experience with any compiler which supports the new
>scope, so I really don't know how other compilers will handle this.  I
>do know that there are a lot of changes for compiler writers to
>integrate, and that it is easy to forget little details like generating
>such warnings in the lot of work to be done.

The volume of test code alone is probably enouch to force most writers
to add this for themselves before making it a feature! ;-)

>I might add that I really doubt that there will be any case in my code
>of the silent change occuring, so even if the compiler did warn, I
>probably won't see it.

I don't follow what you won't see.

>I might add that I very much like the way g++ handles the normal case:
>if the program is illegal under the new rules, but would have been legal
>if the variable declared in the for loop were still in scope, g++
>applies the old scope rule, with a warning.  (I do hope that there is an
>option to turn this off, however, and to use strictly one rule or the
>other.  I've not had time to check the documentation to be sure,
>however.)

We look at it this way.  Either you're writing new code or using
old code.  New code should use the new style.  Hence, such a warning
probably is nifty, but seems to be begging for trouble.  There is obviously
the case where recent code with the old style will be maintained by
programmers some who know the new style and some who don't :-( but
hopefully that's short lived.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

If I want to program a loop, I can comfortably declare
the loop counter inside the 'for', e.g.

for (int i=0; i<LOOPCOUNT; i++) {
  ...
}

But the scope of 'i' reaches somehow outside the loop,
because a second loop cannot have the same declaration.
I would then have to declare 'int i' outside the first
'for' again, or I would have to choose a different name
for the second counter.

If the scope of variables declared inside such statements
as 'for', could be as if declared inside the compound
statement, it would solve this.

Frank van Leeuwen.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <01bbf694$dd2b0f40$904697c2@fvl.iaehv.nl>, fvl@iaehv.nl
says...
> If I want to program a loop, I can comfortably declare
> the loop counter inside the 'for', e.g.
>
> for (int i=0; i<LOOPCOUNT; i++) {
>   ...
> }
>
> But the scope of 'i' reaches somehow outside the loop,

[ ... ]

> If the scope of variables declared inside such statements
> as 'for', could be as if declared inside the compound
> statement, it would solve this.

The committee has already done this, and some copmilers have
implemented it.  Other compiler vendors appear to be attempting to
keep their compilers relatively stable until the standard is finished,
at which point they'll likely carry out lots of changes to conform.

In short, what you want is already required (to the extent that a
draft of a standard can require anything) and it's basically just a
matter of time until you can actually plan on using it.

--
    Later,
    Jerry.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

The scope of the i can not be delared just inside the loop.  to use i in a
second loop just don't redeclare it, just set it to zero:

for( i = 0; i < loopCount; i++)
{

}
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>>>>> "FvL" == F van Leeuwen <fvl@iaehv.nl> writes:

 FvL> for (int i=0; i<LOOPCOUNT; i++) {

 FvL> But the scope of 'i' reaches somehow outside the loop,

No, actually it doesn't.

 FvL> because a second loop cannot have the same declaration.

Your compiler seems to be out of date.  Apparently there was some ambiguity
about the scope of `i' at one point, but the latest draft of the standard is
unambiguous:

|  6.5.3  The for statement                                    [stmt.for]
|...
|3 If  the  for-init-statement is a declaration, the scope of the name(s)
|  declared extends to the end of the for-statement.  [Example:
|          int i = 42;
|          int a[10];
|
|          for (int i = 0; i < 10; i++)
|                  a[i] = i;
|
|          int j = i;        // j = 42
|   --end example]
--
 Michael Cook <mcook@cognex.com>        <http://ftp.cognex.com/~mcook/>
 Telephone: +1 508 650 3251                        Fax: +1 508 650 3336
 Cognex Corporation, One Vision Drive, Natick, Massachusetts 01760-2059
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

F. van Leeuwen wrote:
> for (int i=0; i<LOOPCOUNT; i++) {
>   ...
> }
>
> But the scope of 'i' reaches somehow outside the loop,

The standard now stipulates that the scope of variables declared inside
the for(...) are local to the loop.  However, most compilers have not
caught up yet:

DWP May96 -- "A name introduced by a declaration in a condition is in
scope from its point of declaration until the end of the substatements
controlled by the condition."

john lilley
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <01bbf694$dd2b0f40$904697c2@fvl.iaehv.nl>, "F. van Leeuwen" <fvl@iaehv.nl> wrote:
>If I want to program a loop, I can comfortably declare
>the loop counter inside the 'for', e.g.
>
>for (int i=0; i<LOOPCOUNT; i++) {
>  ...
>}
>
>But the scope of 'i' reaches somehow outside the loop,
>because a second loop cannot have the same declaration.
>I would then have to declare 'int i' outside the first
>'for' again, or I would have to choose a different name
>for the second counter.
>
>If the scope of variables declared inside such statements
>as 'for', could be as if declared inside the compound
>statement, it would solve this.
>
>Frank van Leeuwen.

This feature is already in the standard. In the meantime, if your compiler
does not yet support it, you can get the same effect with the following macro:

        #define for if(0) ; else for

No need to change your source code, the only effect will be that the scope of
'i' is restricted to the inside of the for loop. Once your compiler is
upgraded you can remove the macro (but the code will work correctly even if
you dont).

There is one slight problem with this macro --- any decent compiler is likely
to grumble about the constant conditional.

--
Duncan Booth                                             duncan@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://ourworld.compuserve.com/homepages/D_Booth
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <MPLANET.32cabd74jcoffin989b0b@news.rmi.net> jcoffin@taeus.com (Jerry Coffin) writes:
>In article <01bbf694$dd2b0f40$904697c2@fvl.iaehv.nl>, fvl@iaehv.nl
>says...
>> If I want to program a loop, I can comfortably declare
>> the loop counter inside the 'for', e.g.
>>
>> for (int i=0; i<LOOPCOUNT; i++) {
>>   ...
>> }
>>
>> But the scope of 'i' reaches somehow outside the loop,
>
>[ ... ]
>
>> If the scope of variables declared inside such statements
>> as 'for', could be as if declared inside the compound
>> statement, it would solve this.
>
>The committee has already done this,

Correct.

>and some copmilers have
>implemented it.  Other compiler vendors appear to be attempting to
>keep their compilers relatively stable until the standard is finished,
>at which point they'll likely carry out lots of changes to conform.

We decided to implement it (in Comeau C++ 4.0), and it is set by default.
For transition code, there is an option to turn it off.

>In short, what you want is already required (to the extent that a
>draft of a standard can require anything) and it's basically just a
>matter of time until you can actually plan on using it.

It's not a matter of just planning.  That is, some compilers do support it
now, so it's a matter of actually getting those compilers or not.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5abicd$jdu@erawan.cognex.com> Michael R Cook <mcook@cognex.com> writes:
>...  Apparently there was some ambiguity
>about the scope of `i' at one point, but the latest draft of the standard is
>unambiguous:
>
>|  6.5.3  The for statement                                    [stmt.for]
>|...
>|3 If  the  for-init-statement is a declaration, the scope of the name(s)
>|  declared extends to the end of the for-statement.  [Example:
>|          int i = 42;
>|          int a[10];
>|
>|          for (int i = 0; i < 10; i++)
>|                  a[i] = i;
>|
>|          int j = i;        // j = 42
>|   --end example]

Although the [draft] spec has been changed, it was never ambiguous on
this issue, nor was the identifier.  I think it is important to clarify
this misconception.  It was always quite clear.  The issue was always
one of inconsistency as well as a "simple" matter of programming style.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <01bbf739$2d0f13e0$0fe082d0@roberts_server> "Robert Dobbins" <rdobbins@cyberhighway.net> writes:
>The scope of the i can not be delared just inside the loop.  to use i in a
>second loop just don't redeclare it, just set it to zero:
>
>for( i = 0; i < loopCount; i++)
>{
>
>}

This is not a standard issue but a style issue, since this aspect of
things is really about re-using identifiers, which may or may not be
wise.  As with many things: context rules.  I think the important thing
here in this NG is that to use the id by name in another loop, it can no
longer be declared in the init section of the for since it is no longer
in scope.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]