Container insertion and removal

[Michel Fortin]

On 2010-03-06 07:49:18 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> 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
michel.fortin at michelf.com
http://michelf.com/