STL list::erase() weird action going on

[John Smith]

Today I experienced something very very weird with STL.
The code snippet below should work, but it doesn't with Microsoft VC++ 6.0.

Ok what I have is a list of network connections. The code below removes one
of these connections from a temporary list. It goes through all the items to
find the right connection and removes it by erasing with the matching
iterator.

However what happens is that the item stays in the list after beeing deleted
but another one is deleted though. The size of the list goes down by 1 after
the erase function but the item still stays there. This was verified by
printing out the list after the erase function was called.

Can anyone explain this? My first thought is that it must be a bug in the
compiler.

I solved it by using list::remove() instead.

The list is of type list<CClientConnection *>

void CConnectionList::RemoveConnectionFromInProcessList(CClientConnection
*pC)
{
CConnectionList::iterator it;

// Remove connection from the temporary list
for (it = m_InProcessList.begin(); it != m_InProcessList.end(); it++)
{
if (*it = pC)
{
m_InProcessList.erase(it);
break;
}
}
}

Thanks in advance.
-- John

 

[Ivan Vecerina]

Today I experienced something very very weird with STL.
The code snippet below should work, but it doesn't with Microsoft VC++
6.0. ....
However what happens is that the item stays in the list after beeing
deleted
but another one is deleted though. The size of the list goes down by 1
after
the erase function but the item still stays there. This was verified by
printing out the list after the erase function was called.

Can anyone explain this? My first thought is that it must be a bug in the
compiler.

I solved it by using list::remove() instead.

The list is of type list<CClientConnection *>

void CConnectionList::RemoveConnectionFromInProcessList(CClientConnection
*pC)
{
CConnectionList::iterator it;

// Remove connection from the temporary list
for (it = m_InProcessList.begin(); it != m_InProcessList.end(); it++)
{
if (*it = pC)

You probably intend to write:
if( *it == pC )

{
m_InProcessList.erase(it);
break;
}
}
}

I hope this helps
Ivan

 

[John Smith]

You probably intend to write:

if( *it == pC )

I hope this helps
Ivan

Hehe crap on me
You know... I spent like 6 hours straight to debug and find this pieces of
code. I went through alot of classes and even more threads which uses this
code in parallel. I had many theories about bad mutexes which were
destroying and overlapping the runtime sequence... all to realise it was
such a simple mistake.

Anyway... thanks alot

-- John

 

[Rade]

if (*it = pC)

maybe: if (*it == pC) ?

 

[Greg Schmidt]

Hehe crap on me
You know... I spent like 6 hours straight to debug and find this pieces of
code.

Doesn't VC++6 emit a warning for this code? I'm in the habit of leaving
warnings turned up pretty high and then making sure that all code
compiles warning-free, so that stuff like this doesn't get lost in a
bunch of warnings I know about but don't care to fix.

 

[John Smith]

Doesn't VC++6 emit a warning for this code? I'm in the habit of leaving
warnings turned up pretty high and then making sure that all code
compiles warning-free, so that stuff like this doesn't get lost in a
bunch of warnings I know about but don't care to fix.

No it did not. The normal level is the 2nd highest (/W3) and the highest
(/W4) is quite useless since it gives over 500 warnings from Microsofts own
STL code.
Normally my code is always warning-free this one was just a slip-through.
Oh well... bug fixed and lesson learned.

-- John

 

[Peteris Krumins]

Here is a quote I like:

"Chess mastery is a discipline which places a premium on consistency:
One moment of hallucination can throw away hours of good work.

Someone once asked a grandmaster how to avoid such mistakes, and was
told, "Sit on your hands!"

As with the chess master, the master programmer eventually --- usually
through painful experience -- acquires the habit of stepping back from
each involved coding task once done, clearing the mind, and re-reading
thoroughly with fresh eyes, looking for elementary mistakes.

It is not a natural habit, but once acquired it can make programming
much more pleasant. You may even eventually find your code working
first try on a regular basis, an experience akin to nirvana."

 

[John Smith]

It is not a natural habit, but once acquired it can make programming

much more pleasant. You may even eventually find your code working
first try on a regular basis, an experience akin to nirvana."
--

Actually I managed to solve other bugs at the same time. There were some
overflow bugs which I wouldn't have found otherwise that easily. So all in
all it wasn't all in vain because I refactored and improve the hard-to-read
parts of the code. We're talking about atleast 1500 lines of code I had to
go through and debug (the code related to this problem) so it had to take
some time.

-- John