Re: [boost] [multi_index] User-defined indices

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-12 05:21:19

Hello Joaquin,

Tuesday, June 12, 2007, 1:00:41 AM, you wrote:

> Andrey Semashev <andysem <at> mail.ru> writes:

>> 
>> Hello JOAQUIN,
>> 
>> Monday, June 11, 2007, 1:46:53 AM, you wrote:

[snip]

>> Therefore, if there is:
>> 
>> - a way to tell the index the complete node type and means to extract
>> the container value and index's header form it
>> - a way to tell multi_index_container the type of index's header and
>> iterators
>> - a way to notify the index about modification events (such as insert
>> and erase) performed through other indices (at least on per-node
>> basis)
>> 
>> then there is a quite usable basic interface to implement user's
>> indices.

> The interface is not a passive one like you seem to be describing,
> but an active one in which some operations are performed in
> an orchestrated manner by all the indices. Allow me to give
> a very incomplete description of how indices work internally.
> Rouhgly speaking, an index has the following structure:

[snip]

> where Super contains a linear hierarchy of the preceding indices
> and index_implementation is supposed to derive from this to
> add itself to the chain. The important part is the backbone
> protected interface by which all the important "primitive"
> operations of the multi_index_container are implemented: for
> instance, index_implementation::insert_(...) must do its part
> of the insertion operation and then call Super::insert_(...)
> so that the remaining indices do the same, etc. The public
> member function insert() then resolves to a mere call to this
> primitive operation. As you see, the degree of coupling is
> very high --this has been done so in order to provide maximal
> efficienfy time- and memory-wise.

I'm not sure how you perform insertions then. You have to check if an
element is allowed to be inserted before the insertion. That means any
index in the hierarchy may reject it and all other indices should
remain intact.

Anyway, you've managed to implement it some way. Then you just need to
document the minimum set of these protected members and, additionally,
final_*() members which begin each operation.

But there may be ways of decoupling indices. For example, you may
implement these final_* functions so they call each index's protected
function separately. There would be no need to call base class
recursively in each index and I don't think it's going to make a
performance impact. This is essentially what I was writing above.
In addition this might help to encapsulate exception safety burden
in these final_* functions instead of distributing it in indices.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]