that they
do not invalidate the ranges of their containers. What does it mean to
invalidate a range?
Say for example, you are iterating a red black tree, and your current
front points at a certain node. Then that node is removed from the
tree. That range is now invalid, because the node it points
and
ranges don't tend to get invalidated as easily. As long as you don't
remove
the element (or elements in the case of a range - assuming that it
keeps track
of its two end points, as is likely) that it points to, then adding or
removing elements from the container shouldn't invalidate
in std.container, the stable* container functions advocate that they do
not invalidate the ranges of their containers. What does it mean to
invalidate a range?
my assumption is it means causing e.g. front or popFront to fail when
empty says they should succeed or vice versa.
Ellery Newcomer:
in std.container, the stable* container functions advocate that they do
not invalidate the ranges of their containers. What does it mean to
invalidate a range?
Generally modifying a collection while you iterate on it causes troubles. When
you iterate on a range and you
On 08/12/2011 03:13 PM, bearophile wrote:
Ellery Newcomer:
in std.container, the stable* container functions advocate that they do
not invalidate the ranges of their containers. What does it mean to
invalidate a range?
Generally modifying a collection while you iterate on it causes troubles
On Fri, 12 Aug 2011 15:54:53 -0400, Ellery Newcomer
ellery-newco...@utulsa.edu wrote:
in std.container, the stable* container functions advocate that they do
not invalidate the ranges of their containers. What does it mean to
invalidate a range?
Say for example, you are iterating a red
On 08/12/2011 03:29 PM, Steven Schveighoffer wrote:
On Fri, 12 Aug 2011 15:54:53 -0400, Ellery Newcomer
ellery-newco...@utulsa.edu wrote:
in std.container, the stable* container functions advocate that they
do not invalidate the ranges of their containers. What does it mean to
invalidate
(or elements in the case of a range - assuming that it keeps track
of its two end points, as is likely) that it points to, then adding or
removing elements from the container shouldn't invalidate the iterator/range.
shouldn't isn't a guarantee. Where there is shouldn't, there can't
be stableRemove
invalidated as easily.
As long as you don't remove the element (or elements in the case of a
range - assuming that it keeps track of its two end points, as is
likely) that it points to, then adding or removing elements from the
container shouldn't invalidate the iterator/range.
shouldn't isn't
On 08/12/2011 05:51 PM, Jonathan M Davis wrote:
An implementation can guarantee it as long as your range doesn't directly
point to an element being removed (i.e. as long as the element isn't on the
ends - or maybe one past the end, depending on the implementation). But _no_
container can
On Friday, August 12, 2011 16:16 Ellery Newcomer wrote:
On 08/12/2011 05:51 PM, Jonathan M Davis wrote:
An implementation can guarantee it as long as your range doesn't directly
point to an element being removed (i.e. as long as the element isn't on
the ends - or maybe one past the end,
in the container. This means that removing any
node could potentially invalidate a range somewhere. When such a
conflict arises, you cannot both perform the removal and keep a valid
range, regardless of whether you even knew of the conflict.
it,
in a node based container, [I expect] will be a pointer to a node, which
might point to any node in the container. This means that removing any
node could potentially invalidate a range somewhere. When such a
conflict arises, you cannot both perform the removal and keep a valid
range, regardless
13 matches
Mail list logo
