I have a container where elements might get moved around.

So, for the things iterating it the element points to the iterator and iterator to element so they can be updates when stuff is moved around.

However, i want only a single iterator to point to a element so each element only needs to keep track of and update a single iterator.

But since i want the user to have a nice object to iterate with, i create a class that redirects the commands to the previous iterator. (Is this a proxy?)


So it looks like

Iterator<->Internal iterator<->Container


Currently my container would keep the internal iterators in a vector and when it moves elements around it checks the internal iterator the element points to (index to the vector) and updates it.

The internal iterators are reference counted as there is only need for a single internal iterator for an element even if there are multiple readers. I thought that this also allows putting any kind of multithreading controls (lock thingies and stuff) into the internal iterators so it doesnt add to the size of the individual elements.



Is it ok to have the container handle both internal iterators and elements, or is there a way to separate them? Note that the nodes need to have an index to the internal iterators and the class which moves them around needs to cause the internal iterator to be updated somehow.

Also, what are these kinds of redirecting things called? (so i can index redirector[] with the same value even if the object it redirects to moves around)

I'm finding it difficult to follow what you're saying, but it sounds like it could be greatly simplified by just introducing iterator invalidation akin to that in the standard library. If I [font=courier new,courier,monospace]erase[/font] from a container, my existing iterator is invalidated - I must instead use the one returned by the function.

That almost sounds like you are looking for a mediator.

I want multithreading possibility without having to lock the entire container. This also allows making the iterators polymorphic without the user needing to mess with pointers and allocating each iterator with new.

It sounds like you are mixing an awful lot of potentially unrelated requirements into a single container. I think it would be good to design a test case for the kind of scenarios you are talking about. There is almost certainly an easier way to go about this, and having a concrete example would help such a design to form.