JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Jeffrey Holle <jeffreyholle@bellsouth.net> Fecha: Martes, Octubre 2, 2007 11:08 pm Asunto: Re: [Boost-users] [multi_key] problems using modify_key with a composite_key index Para: Boost Users mailing list <boost-users@lists.boost.org>
While my swap method is now working correctly, I have found the the use of modify on a composite_key in order to preform a swap has corrupted the index.
The very next time I attempt to use it in a statement like this:
for (tie(iter,iter_end)=xyIndex.equal_range(make_tuple(i)); iter!=iter_end;++iter)
The for loop runs forever. I also attempted to print the distance(iter,iter_end) and this function never returns.
Note that it happens that the one time my sort function executed, only a single swap was preformed.
Is there a way to fix this?
I lack the context to give a more informed opinion, so the following is mere speculation: take into account that in a expression of the form
c.modify(it,f);
f is *not* allowed to modify any other element of c except *it. Maybe you are violating this rule in some of your calls to modify()?
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I actually coded my sort function with iterators the first time and found out that it was a no no. Presently, I produce the iterator that modify needs "on-the-fly" using the xyIndex's find method. The situation that I described above is considerable more complicated. By the time my app hangs up in the iteration loop through the elements in row 2, my sort function has executed 4 times, producing a sum of 2 swaps. The arrant behavior of the composite_key index starts appearing at the end of the 3rd sort operation. Then I see that a vertex order of "7,10,9,11" get changed to "11,7". This makes no sense to me, swapping elements shouldn't reduce the number of elements in a row. I'm going to do some experimenting with different types of indexes next. I'm also going to contemplate if the boost::zip_iterator might assist me in this problem.