18 Apr
2012
18 Apr
'12
9:49 p.m.
Calvin, Slavek, Liddell,
I'm trying to fix tdepim to build with gcc47, but I don't understand
how to
make sure I'm fixing the right 'it' iterator. Specifically, the multiple
declaration issue is:
/build/src/tdepim/kmail/kmsystemtray.cpp: In member function 'void
KMSystemTray::updateNewMessages()':
/build/src/tdepim/kmail/kmsystemtray.cpp:485:48: error: redeclaration of
'TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it'
/build/src/tdepim/kmail/kmsystemtray.cpp:475:55: error:
'TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it' previously
declared
here
The code beginning at line 473 is:
void KMSystemTray::updateNewMessages()
{
for ( TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it =
mPendingUpdates.begin();
it != mPendingUpdates.end(); ++it)
{
KMFolder *fldr = it.key();
if ( !fldr ) // deleted folder
continue;
/** The number of unread messages in that folder */
int unread = fldr->countUnread();
TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it =
mFoldersWithUnread.find(fldr);
bool unmapped = (it == mFoldersWithUnread.end());
/** If the folder is not mapped yet, increment count by numUnread
in folder */
if(unmapped) mCount += unread;
/* Otherwise, get the difference between the numUnread in the folder
and
* our last known version, and adjust mCount with that difference */
else
{
int diff = unread - it.data();
mCount += diff;
}
Looking through the comments and context, there seems to be two 'it'
iterators involved:
TQMap<.., bool>::...it
TQMap<.., int>::...it
with the 'bool' declaration being the loop index and the 'int' being
used
to
determine if the folder with unread messages is unmapped. The 'bool' dec
seems
to be the one used to access the class data (i.e. it.key(), it.data()) If
I'm
reading that correctly, then we can correct the 'int' iterator by renaming
it
something like 'unread_it'
TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it =
mFoldersWithUnread.find(fldr);
bool unmapped = (unread_it == mFoldersWithUnread.end());
What say the experts. Is my reading of which 'it' can be renamed
correct?
Yes, you are correct. When dealing with these problems, I look at the way
gcc treated the variable's scope before the change; i.e. within a given
scope (usually a set of curly braces, though there are other ways to
create a temporary scope) once the new "it" object was created, all
accesses to "it" until the end of the current scope (excluding new scopes
within the current scope) are going to be treated as accessing the new
"it" object.
Confused yet? :-)
Tim