to invalidate a range

Ellery Newcomer ellery-newcomer at utulsa.edu
Fri Aug 12 16:16:07 PDT 2011


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 guarantee that an iterator or range which directly references an
> element which is removed is going to stay valid - not without playing some
> serious games internally which make iterators and ranges too inefficent, and
> possibly not even then. So, stableRemove is only going to guarantee that a
> range stays valid on as long as the end points of that range aren't what was
> being removed.

Forgive my being dense, but where is this 'as long as' coming from? If 
your range only points to ends in e.g. a linked list, how is it supposed 
to retrieve elements in the middle? I'm having a hard time visualizing a 
range over a node based container that doesn't point to a node in the 
middle (at some point in time). The range points to the node to retrieve 
the current front quickly, the node can get removed, the removed 
function won't know its invalidating the range without playing yon 
internal games, ergo stable remove cannot be.


More information about the Digitalmars-d-learn mailing list