Erik Wikström
11/16/2008 5:23:00 PM
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