[multi-index] runtime indices
Hi all, I have been using multi-index with great success, but have struck a requirement that sort of fits into the remit of multi-index, but isn't catered for. Here's what I want to do (pseudocode) typedef multi_index<MyClass> MyIndex; MyIndex mi; int index_id = 0; mi.add_sorted_index( index_id++, MyIndex::sorted_index_predicate_type( &some_predicate ) ); mi.add_sorted_index( index_id++, MyIndex::sorted_index_predicate_type( &some_other_predicate ) ); So basically, add indices at runtime, to take advantage of multi_index's great features, such as projection, index updating on modification, etc. My use case, if it's relevant, is to expose multi_index behaviour on objects from a dll. Where obviously the calling module can't specify at compile time the required indices. Is this a sensible addition to multi-index, or is it best implement using other mechanisms. (Having to re-implement many of the great features of multi-index doesn't seem desireable.) Neil
Neil Hunt escribió:
Hi all,
I have been using multi-index with great success, but have struck a requirement that sort of fits into the remit of multi-index, but isn't catered for.
[...]
So basically, add indices at runtime, to take advantage of multi_index's great features, such as projection, index updating on modification, etc.
[...]
Is this a sensible addition to multi-index, or is it best implement using other mechanisms. (Having to re-implement many of the great features of multi-index doesn't seem desireable.)
Hello Neil, This is a non-trivial addition to Boost.MultiIndex. In fact, a run-time multi_index_container would be a different beast than the classic multi_index_container in important aspects: 1. multi_index_container memory usage is very efficient as internal nodes pack all the (statically known) indices' headers into one big structure. In the run-time case, this cannot be done and we would necessitate smarter internal structures, incurring at least one extra pointer per node per index. Also, if we allow to add indices to a non-empty container things become much harder --existing nodes would have to be added the extra index info. 2. If we wish our run-time multi_index_container to provide an index-retrieving facility akin to get<N> in the classical multi_index_container, some sort of type erasure needs to be resorted to. This could be given a nice treatment using some library for dynamic polymorphism such as Turkanis' candidate Boost.Interfaces (http://www.coderage.com/interfaces/ ), which unfortunately never made it into Boost. FWIW, I investigated this problem in 2006 and sketched some ideas in code. My conclusion was that the thing is doable but complicated, and I saw no real demand for it. I don't think I'll resume that task --sorry. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
joaquin＠tid.es -
Neil Hunt