Boost.MultiIndex Future work

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

Several STL implementations feature hashed sets as a natural
counterpart to std::set and std::multiset.
multi_index_container can also benefit from the inclusion of hashed
indices. As the exact details of the interfaces of hashed sets differ among
library vendors, a good starting point seems Matt Austern's paper
A
Proposal to Add Hash Tables to the Standard Library (revision 4), which
has been submitted for acceptance into the next revision of the
C++ standard.

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 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:

Logging,

interfacing to GUI-based applications,

synchronization between separate data structures.

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

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:

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.

Example 4 in the examples section
features a bidirectional map, implemented as an
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.

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;// OKcout<<m["zero"]<<endl;// OKm[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.

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_containers 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_containers. Without support
for move semantics, this scheme is impractical and less elegant syntaxes
should be resorted to.