trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: May 2012

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

From: "E. Liddell" <ejlddll@...>
Date: Sat, 26 May 2012 20:16:33 -0400
On Sat, 26 May 2012 18:03:46 -0500
"David C. Rankin" <drankinatty@...> wrote:

> On 05/26/2012 02:54 AM, Francois Andriot wrote:
> > 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
> > 
> 
> Thank you Francios,
> 
>   In this case, the 'it' declared at 475 isn't unreferenced until the 475 for
> loop ends at line 548. That's what makes this unclear to me. The problem I must
> not be explaining correctly is this (starting line 475):
> 
>   for ( TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it = mPendingUpdates.begin();
>         it != mPendingUpdates.end(); ++it)
>   {
> 
>   <snip - next line 485 (originally '::Iterator it') >
> 
>   TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it =
>       mFoldersWithUnread.find(fldr);
> 
>   <snip - next line 496>
> 
>     int diff = unread - it.data();
> 
>   <snip - next line 548 - closing for>
> 
>   }
> 
>   Since there are no bounding braces '{}' for the line 485 redeclaration, there
> is nothing that specifically limits the scope of the 485 redeclaration. So if in
> the code between 485 and 548 there were additional references to 'it.something',
> how can you tell whether it is the it from the 475 declaration or the 'it' (now
> unread_it) that belongs to 485 redeclaration? What if there was at say line 530
> something like:
> 
>   KMFolder *prev_fldr_with_unread = it.key() - jump;
> 
>   Can you say that just because there was a redeclaration at 485, that the 'it'
> at line 530 must be associated with with the redeclaration, even though it is
> still within the code-block for the original it?

In a word, yes—an inline declaration like that one should be valid until the end
of the scope in which it was made, just like Francois said.  It doesn't matter
whether there's a chunk of code between the beginning of the scope and the
declaration.