Re: [Boost-users] [multi_key] problems using modify_key with a composite_key index

From: Jeffrey Holle (jeffreyholle_at_[hidden])
Date: 2007-10-02 18:11:49

JOAQUIN LOPEZ MU?Z wrote:
> ----- Mensaje original -----
> De: Jeffrey Holle <jeffreyholle_at_[hidden]>
> 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_at_[hidden]>
> 
>> 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.