redefinition inside for loop

[pauldepstein]

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)

{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Is there an ANSI standard that says that you can redefine variables
inside a for-loop?

Or is this regarded as not being a redefinition because the definition
is only written once?

I'd be grateful if someone could explain why the above code compiles
but {//some code
double x=5; double x=6; // more code} gives a redefinition error.

Thank you,

Paul Epstein

[Rolf Magnus]

pa**********@att.net wrote:

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)

{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Why do you consider that a problem?

Is there an ANSI standard that says that you can redefine variables
inside a for-loop?

What do you mean by "redefine"? You define it only once. it gets created at
the point of definition and destroyed at the end of the scope, just like
any other (non-static) local variable. So on each iteration it gets created
and destroyed.

Or is this regarded as not being a redefinition because the definition
is only written once?

I'd be grateful if someone could explain why the above code compiles
but {//some code
double x=5; double x=6; // more code} gives a redefinition error.

Because you define two variables with the same name in the same scope. In
your for loop, you don't have that.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-25 05:54, pa**********@att.net wrote:

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)

{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Is there an ANSI standard that says that you can redefine variables
inside a for-loop?

No, but there is one that allows you to redefine a variable in a new scope.

Or is this regarded as not being a redefinition because the definition
is only written once?

I'd be grateful if someone could explain why the above code compiles
but {//some code
double x=5; double x=6; // more code} gives a redefinition error.

You can not have two variables with the same name in the same scope.

--
Erik Wikström

[Jonathan Lane]

On Oct 25, 4:54 am, [e-mail] wrote:

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)

{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Is there an ANSI standard that says that you can redefine variables
inside a for-loop?

Or is this regarded as not being a redefinition because the definition
is only written once?

I'd be grateful if someone could explain why the above code compiles
but {//some code
double x=5; double x=6; // more code} gives a redefinition error.

Thank you,

Paul Epstein

x is created within the scope of the loop. in your case it's put on
the stack. At the end of the loop, the stack unwinds and it gets
removed. You then start through the loop again and create a new
variable called x on the stack. It uses the same slot in the stack but
is still a different object.

Consider:

for (int i = 0; i < 5; ++i)
{
double* x = new double(5);
delete x;
}

This does the same thing as your code but on the heap so it might be a
little clearer.

[James Kanze]

On Oct 25, 9:48 am, Erik Wikström <[e-mail]:

On 2007-10-25 05:54, [e-mail] wrote:

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)
{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Is there an ANSI standard that says that you can redefine
variables inside a for-loop?

No, but there is one that allows you to redefine a variable in
a new scope.

It's a bit trickier than that; in this case, I think that the
for introduces a new scope. Think of it for a moment:

for ( int i = 0 ; i < 10 ; ++ i )
MyClassType c ;

If the for doesn't introduce a new scope, where does c get
destructed? (In the early days, this wasn't that clear, and a
lot of compilers would call the destructor of c at the next }.
Even if the conditions of the for loop meant that it was never
executed.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[terminator]

On Oct 25, 6:54 am, [e-mail] wrote:

On my visual c++ compiler, I compiled code which contained something
like

for( int i =0; i < 5; i++)

{ double x =5;}

I expected it to give a compiler error because x is being redefined
and redeclared each time through the loop.

Is there an ANSI standard that says that you can redefine variables
inside a for-loop?

Or is this regarded as not being a redefinition because the definition
is only written once?

I'd be grateful if someone could explain why the above code compiles
but {//some code
double x=5; double x=6; // more code} gives a redefinition error.

let us call every pair of { and } a block statment.then any acceptable
identifier can be defined exactly once in each block statement.A block
nested in another block can access the identifiers defined in the
nesting block or hide them via redefining them .

regards,
FM.

[Rolf Magnus]

James Kanze wrote:

Is there an ANSI standard that says that you can redefine
variables inside a for-loop?

>No, but there is one that allows you to redefine a variable in
a new scope.

It's a bit trickier than that; in this case, I think that the
for introduces a new scope. Think of it for a moment:

for ( int i = 0 ; i < 10 ; ++ i )
MyClassType c ;

If the for doesn't introduce a new scope, where does c get
destructed?

Same for the variable i.

[James Kanze]

On Oct 25, 6:47 pm, Rolf Magnus <[e-mail]:

James Kanze wrote:

Is there an ANSI standard that says that you can redefine
variables inside a for-loop?

No, but there is one that allows you to redefine a variable in
a new scope.

It's a bit trickier than that; in this case, I think that the
for introduces a new scope. Think of it for a moment:

for ( int i = 0 ; i < 10 ; ++ i )
MyClassType c ;

If the for doesn't introduce a new scope, where does c get
destructed?

Same for the variable i.

Yes. But that's also an intentional change.

As far as I can tell, early (pre-standard) C++ didn't really
specify the lifetime of something like c, above. Generally
speaking, the rule was that the variable had a scope until the
end of the block, which would (logically) mean:

for ( int i = 0 ; i < 10 ; i ++ )
MyClassType c ;
c.doSomething() ; // c still valid here !!!

IIRC, many early compilers did allow this, calling the
constructor of c each time through the loop (and not at all if
the loop executed 0 times), and calling the destructor once at
the end of the enclosing block. As you can imagine, this didn't
work out too well in practice. (IIRC, too, CFront---which only
destructed temporaries at the end of the block---did the same
thing with temporaries. Including any generated in condition or
the increment parts of the for. I definitely once had a problem
with a temporary returned by the increment part. And while
something like the above is really unlikely in actual code,
temporaries aren't.)

Because of the obvious problems, the rule was very quickly
changed that objects declared in a conditional statement had the
scope of that statement; i.e. c, above, had the scope of the for
statement. (I think this change was even before standardization
began---in fact, it may have been the rule from the start, and
just have been poorly implemented by the compilers I was using.)

When dynamic_cast was introduced, the grammar was modified to
allow a declaration in the condition; this declaration was given
the scope of the statement. Only after that was it felt that
this made the longer scope of the variable in the initialization
part of the for inconsistent, so its scope was changed. (There
had been a proposal earlier to change it; at that time, it was
generally agreed that the scope should have been that of the for
statement, but that changing it at that time would involve
breaking too much code. By the time dynamic_cast was added,
however, the dynamics of the committee had changed, and nobody
cared about existing code.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[terminator]

On Oct 26, 11:16 am, James Kanze <[e-mail]:

On Oct 25, 6:47 pm, Rolf Magnus <[e-mail]:

James Kanze wrote:

Is there an ANSI standard that says that you can redefine
variables inside a for-loop?
>No, but there is one that allows you to redefine a variable in
>a new scope.
It's a bit trickier than that; in this case, I think that the
for introduces a new scope. Think of it for a moment:
for ( int i = 0 ; i < 10 ; ++ i )
MyClassType c ;
If the for doesn't introduce a new scope, where does c get
destructed?

Same for the variable i.

Yes. But that's also an intentional change.

As far as I can tell, early (pre-standard) C++ didn't really
specify the lifetime of something like c, above. Generally
speaking, the rule was that the variable had a scope until the
end of the block, which would (logically) mean:

for ( int i = 0 ; i < 10 ; i ++ )
MyClassType c ;
c.doSomething() ; // c still valid here !!!

IIRC, many early compilers did allow this, calling the
constructor of c each time through the loop (and not at all if
the loop executed 0 times), and calling the destructor once at
the end of the enclosing block. As you can imagine, this didn't
work out too well in practice. (IIRC, too, CFront---which only
destructed temporaries at the end of the block---did the same
thing with temporaries. Including any generated in condition or
the increment parts of the for. I definitely once had a problem
with a temporary returned by the increment part. And while
something like the above is really unlikely in actual code,
temporaries aren't.)

Because of the obvious problems, the rule was very quickly
changed that objects declared in a conditional statement had the
scope of that statement; i.e. c, above, had the scope of the for
statement. (I think this change was even before standardization
began---in fact, it may have been the rule from the start, and
just have been poorly implemented by the compilers I was using.)

When dynamic_cast was introduced, the grammar was modified to
allow a declaration in the condition; this declaration was given
the scope of the statement. Only after that was it felt that
this made the longer scope of the variable in the initialization
part of the for inconsistent, so its scope was changed. (There
had been a proposal earlier to change it; at that time, it was
generally agreed that the scope should have been that of the for
statement, but that changing it at that time would involve
breaking too much code. By the time dynamic_cast was added,
however, the dynamics of the committee had changed, and nobody
cared about existing code.)

Sorry to terminate again;I can not see what the scope of for
initializer is .I used to take the following two as equivalent code:

_1st:
for(int init =0 ;condition ;inrement)
statement;

_2nd:
start_loop:{
int init=0;
for(;condition;increment)
{statement;};
};//destroy init

regards,
FM.

[James Kanze]

On Oct 27, 11:08 am, terminator <[e-mail]:

On Oct 26, 11:16 am, James Kanze <[e-mail]:

Sorry to terminate again ;I can not see what the scope of for
initializer is. I used to take the following two as equivalent
code:

_1st:
for(int init =0 ;condition ;inrement)
statement;

_2nd:
start_loop:{
int init=0;
for(;condition;increment)
{statement;};

};//destroy init

They are at present. They didn't used to be; in the (now fairly
distant) past, the equivalent of the first was simply:

int init=0 ;
for ( ; condition ; increment )
statement ;

I don't think that there was even an implicit {...} around the
statement, and there certainly wasn't one around the for
itself; any variables declared in the initialization part had a
lifetime corresponding to that of the block surrounding the for.
And code like:

for ( int i = 0 ; i < last && ! condition ; i ++ ) {
}
return i ;

was quite frequent.

The fact that "statement" had a scope until the end of the block
is an obvious oversight, since it cannot be made to work. It
was fixed very, very early. At more or less the same time, the
committee considered the possibility of reducing the scope of a
variable declared in the initialization part of a for. The
consensus at the time was, I think, that while it would be
cleaner, there was to much code in existence like the example
immediately above, which would break, and that such a change
would be irresponsible.

Much, much later---as part of the dynamic_cast proposal---the
possibility of defining a variable in a "condition" (if, while
or second part of a for) was introduced. After that, it was
felt that having different scopes for two variables, both
defined in a for loop, was too counter-intuitive, so the scope
of the variable in the initialization part of the for loop was
changed. (Responsibility wasn't an "in" word in the committee
at that point in time. IMHO, being able to declare a variable
in a condition is, itself, a mis-feature, but since no one is
required to use it, it doesn't bother me too much. Breaking
existing code did, but there wasn't much I could do about it.)

This change was fairly late in the standards proceedings; just
before CD1, I think. Many compilers didn't implement it
immediately, probably to avoid breaking existing code. Even
today, most compilers have an option to use the old for scope,
precisely so that old code can compile.

Note that the change can silently change the semantics of a
program. Consider:

static int i = 2 ;

int
f( int n )
{
for ( int i = 0 ; i < n ; ++ i ) {
}
return i ;
}

f(10) will return 10 under the old rules, 2 under the new. In
practice, I doubt that this is ever a problem in well written
code, since you normally wouldn't give a variable in local scope
the same name as one with namespace (or class) scope. (A good
general rule is that the length of a name is inversely
proportional to its visibility. Local variables, particularly
loop control variables, can have very, very short names, like i,
where as anything visible outside a single function requires a
somewhat longer, more meaningful name.)

FWIW: the version of g++ that I have on my machine (4.1.2) will
issue a warning for this code, by default (and use the new
rule). It also has an option (-fno-for-scope) to silently use
the old rule. (I had thought that -ffor-scope would turn off
the warning, but it doesn't seem to.)

Also, I believe that VC++ 6.0 (still widely used!) still
implemented the old rule---it did appear before the standard was
adopted.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]