# Boost.MultiIndex Future work

Tests
Index
Release notes

A number of new functionalities are considered for inclusion into future releases of Boost.MultiIndex. Some of them depend on the potential for extensibility of the library, which has been a guiding principle driving the current internal design of `multi_index_container`.

## Contents

- Ranked indices
- Notifying indices
- Constraints
- User-defined indices
- Bidirectional map
- Indexed maps
- Move semantics

## Ranked indices

Ordered indices are implemented using red-black trees; these trees can be augmented with additional information to obtain a type of data structure called order-statistics trees, allowing for logarithmic search of the n-th element. It has been proposed that order-statistics trees be used to devise a new type of ranked indices that support `operator[]` while retaining the functionality of ordered indices.

## Notifying indices

Notifying indices can be implemented as decorators over preexistent index types, with the added functionality that internal events of the index (insertion, erasing, modifying of elements) are signalled to an external entity --for instance, by means of the Boost.Signals library. This functionality can have applications for:

1. Logging,
2. interfacing to GUI-based applications,
3. synchronization between separate data structures.

The following is a sketch of a possible realization of notifying indices:

>     struct insert_log
>     {
>       void operator()(int x)
>       {
>         std::clog<<"insert: "<<x<<std::endl;
>       }
>     };

>     int main()
>     {
>       typedef multi_index_container<
>         int,
>         indexed_by<
>           notifying<ordered_unique<identity<int> > >, // notifying index
>           ordered_non_unique<identity<int> >
>         >
>       > indexed_t;

>       indexed_t t;

>       // on_insert is the signal associated to insertions
>       t.on_insert.connect(insert_log());

>       t.insert(0);
>       t.insert(1);

>       return 0;
>     }

>     // output:
>     //   insert: 0
>     //   insert: 1

## Constraints

The notifying indices functionality described above exploits a powerful design pattern based on index adaptors, decorators over preexistent indices which add some functionality or somehow change the semantics of the underlying index. This pattern can be used for the implementation of constraints, adaptors that restrict the elements accepted by an index according to some validation predicate. The following is a possible realization of how constraints syntax may look like:

>     struct is_even
>     {
>       bool operator()(int x)const{return x%2==0;}
>     };

>     typedef multi_index_container<
>       int,
>       indexed_by<
>         constrained<ordered_unique<identity<int> >,is_even>
>       >
>     > indexed_t;

## User-defined indices

The mechanisms by which Boost.MultiIndex orchestrates the operations of the indices held by a `multi_index_container` are simple enough to make them worth documenting so that the (bold) user can write implementations for her own indices.

## Bidirectional map

Example 4 in the examples section features a bidirectional map, implemented as a `multi_index_container` with two unique ordered indices. This particular structure is deemed important enough as to provide it as a separate class template, relying internally in `multi_index_container`. As feedback is collected from the users of Boost.MultiIndex, other singular instantiations of `multi_index_container` might be encapsulated to form a component library of ready to use containers.

## Indexed maps

`multi_index_container` is rich enough to provide the basis for implementation of indexed maps, i.e. maps which can be looked upon several different keys. The motivation for having such a container is mainly aesthetic convenience, since it would not provide any additional feature to similar constructs based directly on `multi_index_container`.

The main challenge in writing an indexed map lies in the design of a reasonable interface that resembles that of `std::map` as much as possible. There seem to be fundamental difficulties in extending the syntax of a `std::map` to multiple keys. For one example, consider the situation:

>     indexed_map<int,string,double> m;
>     // keys are int and string, double is the mapped to value

>     ...

>     cout<<m[0]<<endl;      // OK
>     cout<<m["zero"]<<endl; // OK
>     m[1]=1.0;              // !!

In the last sentence of the example, the user has no way of providing the `string` key mapping to the same value as `m[1]`. This and similar problems have to be devoted a careful study when designing the interface of a potential indexed map.

## Move semantics

Andrei Alexandrescu introduced a technique for simulating move constructors called Mojo (see his article in C/C++ User Journal "Generic<Programming>: Move Constructors".) Move semantics alleviates the computational load involved in the creation and copying of temporary objects, specially for heavy classes as `multi_index_container`s are. David Abrahams and Gary Powell provide an alternative implementation of move semantics in their paper "Clarification of Initialization of Class Objects by rvalues" for the C++ Evolution Working Group.

Adding move semantics to `multi_index_container` is particularly beneficial when the container is used as an internal building block in other libraries (vg. relational database frameworks), enabling the efficient development of functions returning `multi_index_container`s. Without support for move semantics, this scheme is impractical and less elegant syntaxes should be resorted to.

Tests
Index
Release notes

Revised February 6th 2006

© Copyright 2003-2006 Joaquín M López Muñoz. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)