they say map::insert doesn't change iterators [modified]
-
(and they are right, technically) I have a map[int /*id*/, somedata], which has a method
Map::MoveRangeTo(int targetID, Map & targetMap, int firstID, int lastID)
{
// some pseudocode:
if (this == &target) // check that ranges don't overlap
ASSERT(targetIDlastID);Map::iterator it startAt, endAt;
GetRange(startAt, endAt, firstID, lastID);
// this returns the STL range with all values in [first, last].
// GetRange works correctly.for(iterator it = startAt; it != endAt; ++it)
{
targetMap[it->first + targetID-firstID] = it->second; // flat copy
it->second = null; // ..and set as "unused" in source
}
erase(startAt, endAt); // remove all null values from source map
}I thought there can't be problems with IDs changing due to the insert operation in the target. Yet apaprently, there is a case where the loop doesn't terminate. Hint1: targetMap=sourceMap Hint2: STL ranges are iterator to first, and iterator behind last -- modified at 7:12 Thursday 7th December, 2006
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
(and they are right, technically) I have a map[int /*id*/, somedata], which has a method
Map::MoveRangeTo(int targetID, Map & targetMap, int firstID, int lastID)
{
// some pseudocode:
if (this == &target) // check that ranges don't overlap
ASSERT(targetIDlastID);Map::iterator it startAt, endAt;
GetRange(startAt, endAt, firstID, lastID);
// this returns the STL range with all values in [first, last].
// GetRange works correctly.for(iterator it = startAt; it != endAt; ++it)
{
targetMap[it->first + targetID-firstID] = it->second; // flat copy
it->second = null; // ..and set as "unused" in source
}
erase(startAt, endAt); // remove all null values from source map
}I thought there can't be problems with IDs changing due to the insert operation in the target. Yet apaprently, there is a case where the loop doesn't terminate. Hint1: targetMap=sourceMap Hint2: STL ranges are iterator to first, and iterator behind last -- modified at 7:12 Thursday 7th December, 2006
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!Not sure about the map issue yet but this is iffy:
if (this == &target) // check that ranges don't overlap ASSERT(targetIDlastID);what if someone uses this code in an environment where ASSERT goes away in release mode?Todd Smith
-
Not sure about the map issue yet but this is iffy:
if (this == &target) // check that ranges don't overlap ASSERT(targetIDlastID);what if someone uses this code in an environment where ASSERT goes away in release mode?Todd Smith
The check is implicit in the caller, I just put it there to note that I though of overlapping. At least I thought I thought of it :cool: The problem is: endAt points to one after the last one to copy (id=149), and for specific target IDs, the item get moved to before endAt. (you are right, though. For a publicly exposed method there should be a runtime check, as it is cheap)
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!