On 2010-03-06 07:49:18 -0500, Andrei Alexandrescu
<[email protected]> said:
Methods such as insert, remove, pushFront, pushBack, removeFront,
removeBack, are assumed to affect the container's topology and must be
handled in user code as such.
I think it'd be better to say "they are assumed to invalidate linked
ranges". I know it's the same thing, but I think it's preferable to
state the effect on the container's interface than the effects on the
container's internals.
Side note: me thinks it'd be better to rename pushFront and pushBack to
insertFront and insertBack. One reason for this is that "push" is often
seen as the opposite of "pop" in container parlance while in our case
it's not. Also, "insert" is a more natural opposite for "remove". And
you're already using the "insert" term standalone anyway when it's not
accompanied by "Front" or "Back".
In addition to those, a container may also define functions named after
the above by adding a "soft" prefix (e.g. softInsert, softRemove...)
that are guaranteed to not affect the ranges currently iterating the
container.
I think that's a good idea. The problem is that you don't necessarily
know when writing an algorithm whether you are authorized or not to
invalidate iterators. Wouldn't it be more useful if it worked with a
wrapper instead?
auto range = container[];
playWithContainer(container.softwrap); // playWithContainer can't
invalidate range
playWithRange(range); // range is still valid here
The soft wrapper could be build automatically from compile time
reflection by looking at which soft methods are available.
--
Michel Fortin
[email protected]
http://michelf.com/
