Re: STL container relocated in memory!? (shifting sands)
On 2008-11-16 17:52, Olumide wrote:
Hello -
To begin with, I'm not the most experienced STL use out there but I'm
slowly getting there. One bug(?) that's plagued me of recent is the
way the OS (or is it STL?) appears to relocate a container in memory
if for example the container needs to grow, with the result that any
references (iterators included) to items in such a container cease to
be valid and may return the address 0xCDCDCD or 0xDDDDDD in the
windows environment (I now know what these pointers mean). I haven't
read the standard but I'm guessing it there's something about elements
of some(?) containers needing to be stored contiguously in memory, and
as such the runtime(?) may relocate a container to guarantee this. Is
this so?
Yes, some of the standard containers may re-locate the elements which
causes invalidation of any iterators and/or pointers to the elements.
Also, lately, its happened that while in the middle of a series of
function calls that do nothing to alter (i.e. grow) the container, an
existing iterator to the container ceases to be valid, apparently the
container has been moved, or so it seems.
That should not happen, if you do not add or remove elements in the
container the elements should stay in place.
Oddly, lists are not so affected i.e. when I change the type of test
to list<int > , the problem no longer happens:
Yes, node-based containers (such as list, set, and map) does not
relocate elements, this is because each element is a node with pointers
to other elements. When you insert/remove elements you only have to
update the pointers and not move the nodes.
I guess I've partly figured out the problem, but I'd appreciate more
insight on this problem/feature.
Any good reference to the standard library should specify if an
operation can invalidate iterators.
--
Erik Wikstr??m