trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: May 2012

Re: [trinity-devel] Commit c94de3af (GCC 4.7 fix) × KMail

From: Francois Andriot <francois.andriot@...>
Date: Sat, 26 May 2012 09:54:14 +0200
Le 26/05/2012 01:21, David C. Rankin a �crit :
>
> OK,
>
>    I see how that happened, but I still don't think I could have discerned
> whether the 'it' at 496 went with the 'it' from 475 or the 'it' from 485 since
> it is within the code-block for TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator
> it, but it is _not_ expressly in the code-block for
> TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it
>
>    How would you know which 'it' needed to go to 'unread_it' or 'it' in this
> case?  When we went over it before, the way was to start with the inner-most
> 'it' and work out from there to separate code-blocks. That didn't work in this
> case. Any other tricks?
>


Hello,
in the original code, the "it" is first declared in a "for" statement 
(line 475), then redeclared differently inside this "for" loop. (line 485).
Inside that loop, any "it" usage BEFORE the redeclaration (line 476 to 
484) refer the first declaration, and any "it" AFTER the redeclaration 
(line 486 to end of loop) refer to the new declaration. The 
redeclaration implies that the original variable is unreferenced, so it 
cannot be used anymore.

So, when you rename the variable of a conflicting redeclaration (this is 
mandatory for GCC 4.7), you must update all references to this variable 
that come AFTER the redeclaration too.

Francois