132
would enable optimizing the overall algorithm by using an auxiliary copy of the element se-
quence containing only items in the change set. This optimization would also eliminate the
need for the first nested if-statement at the start of the code in Figure 6.7, which checks for
the membership of an insertion segment in the change set.
process(cur_seg, mc_stack, enumerate, version)
if cur_seg.type() = insertion
if this segment is in version
if cur_set is marked as part of a move destination, and
that destination is not on mc_stack then
return cur_seg.finalSegment().next()
enumerate(cur_seg)
return cur_seg.next()
else
return cur_seg.finalSegment().next()
endif
else if cur_seg.type() == moveDestination
|| cur_seg.type() == copyDestination
push operation on mc_stack
return cur_seg.getSource.start()
F F F F iii ig g g gu u u ur r r re e e e 6666....7777:::: AAAAuuuuxxxxiiiilllliiiiaaaarrrryyyy ffffuuuunnnnccccttttiiiioooonnnn ffffoooorrrr pppprrrroooocccceeeessssssssiiiinnnngggg aaaa sssseeeeggggmmmmeeeennnntttt dddduuuurrrriiiinnnngggg eeeennnnuuuummmmeeeerrrraaaattttiiiioooonnnn
The handling of move and copy during enumeration is perhaps not obvious. The strategy
used is based on the fact that moved subsequences nest hierarchically at their destination,
because the entire region of addresses created by a move or copy is inserted at one place. Of
course, other subsequences may also occur within such a region. There are two sorts of sub-
sequence that can occur in a move destination:
1. Data inserted in the source range of a move or copy always has an address whose
path starts with the ID of the move or copy. All such addresses have counterparts
without this path prefix, at the source of the operation.
2. Data inserted at the target of a move or copy may have any kind of address, de-
pending on its source (move, copy, or insertion).
As discussed in Section 3.4.2a, addresses within move destinations are usually best repre-
sented at the move’s source because it allows additional merge possibilities by reducing the
would enable optimizing the overall algorithm by using an auxiliary copy of the element se-
quence containing only items in the change set. This optimization would also eliminate the
need for the first nested if-statement at the start of the code in Figure 6.7, which checks for
the membership of an insertion segment in the change set.
process(cur_seg, mc_stack, enumerate, version)
if cur_seg.type() = insertion
if this segment is in version
if cur_set is marked as part of a move destination, and
that destination is not on mc_stack then
return cur_seg.finalSegment().next()
enumerate(cur_seg)
return cur_seg.next()
else
return cur_seg.finalSegment().next()
endif
else if cur_seg.type() == moveDestination
|| cur_seg.type() == copyDestination
push operation on mc_stack
return cur_seg.getSource.start()
F F F F iii ig g g gu u u ur r r re e e e 6666....7777:::: AAAAuuuuxxxxiiiilllliiiiaaaarrrryyyy ffffuuuunnnnccccttttiiiioooonnnn ffffoooorrrr pppprrrroooocccceeeessssssssiiiinnnngggg aaaa sssseeeeggggmmmmeeeennnntttt dddduuuurrrriiiinnnngggg eeeennnnuuuummmmeeeerrrraaaattttiiiioooonnnn
The handling of move and copy during enumeration is perhaps not obvious. The strategy
used is based on the fact that moved subsequences nest hierarchically at their destination,
because the entire region of addresses created by a move or copy is inserted at one place. Of
course, other subsequences may also occur within such a region. There are two sorts of sub-
sequence that can occur in a move destination:
1. Data inserted in the source range of a move or copy always has an address whose
path starts with the ID of the move or copy. All such addresses have counterparts
without this path prefix, at the source of the operation.
2. Data inserted at the target of a move or copy may have any kind of address, de-
pending on its source (move, copy, or insertion).
As discussed in Section 3.4.2a, addresses within move destinations are usually best repre-
sented at the move’s source because it allows additional merge possibilities by reducing the
