Academic movitations aside, there is a practical interest in emulating standard
associative containers by means of multi_index_container, namely to take
advantage of extended functionalities provided by multi_index_container for
lookup, range querying and updating.

The emulation of std::multisets with multi_index_container
results in a slight difference with respect to the interface offered: the member
function insert(const value_type&) does not return an
iterator as in std::multisets, but rather a
std::pair<iterator,bool> in the spirit of std::sets.
In this particular case, however, the bool member of the returned
pair is always true.

The case of std::maps and std::multimaps does not lend
itself to such a direct emulation by means of multi_index_container. The main
problem lies in the fact that elements of a multi_index_container are treated
as constant, while the std::map and std::multimap handle
objects of type std::pair<const Key,T>, thus allowing for free
modification of the value part. To overcome this difficulty we need to create an ad
hoc pair class:

Unlike as with standard sets, the interface of these multi_index_container-emulated
maps does not exactly conform to that of std::maps and
std::multimaps. The most obvious difference is the lack of
operator [], either in read or write mode; this, however, can be
emulated with appropriate use of find and insert.

These emulations of standard associative containers with multi_index_container
are comparable to the original constructs in terms of space and time efficiency.
See the performance section for further details.

Unlike the case of associative containers, emulating std::list
in Boost.MultiIndex does not add any significant functionality, so the following
is presented merely for completeness sake.

Much as with standard maps, the main difficulty to overcome when emulating
std::list derives from the constant nature of elements of a
multi_index_container. Again, some sort of adaption class is needed, like
for instance the following:

Given a multi_index_container instantiation, the following nested types are
provided for compile-time inspection of the various types occurring in the
definition of the multi_index_container:

index_specifier_type_list,

index_type_list,

iterator_type_list,

const_iterator_type_list.

Each of these types is an MPL sequence with as many elements as indices
comprise the multi_index_container: for instance, the n-th
element of iterator_type_list is the same as
nth_index<n>::type::iterator.

A subtle but important distinction exists between
index_specifier_type_list and index_type_list:
the former typelist holds the index specifiers
with which the multi_index_container instantiation was defined,
while the latter gives access to the actual implementation classes
corresponding to each specifier. An example will help to clarify
this distinction. Given the instantiation:

This possibility enables the synthesis of instantiations of
multi_index_container through MPL metaprograms, as the following
example shows:

// original multi_index_container instantiationtypedefmulti_index_container<int,indexed_by<ordered_unique<identity<int>>>>indexed_t1;// we take its index list and add an indextypedefboost::mpl::push_front<indexed_t1::index_specifier_type_list,sequenced<>>::typeindex_list_t;// augmented multi_index_containertypedefmulti_index_container<int,index_list_t>indexed_t2;