Additional Features

| Home | Libraries | People | FAQ | More

### Additional Features

##### N-1, N-N, hashed maps

This is a very interesting point of the design. The framework introduced in std::set theory permits the management of the different constraints with a very simple and conceptual approach. It is easy both to remember and to learn. The idea here is to allow the user to specify the collection type of each key directly. In order to implement this feature, we have to solve two problems:

- The index types of the `multi_index_container` core now depends on the collection type used for each key.
- The map views now change their semantics according to the collection type chosen.

Boost.Bimap relies heavily on Boost.MPL to implement all of the metaprogramming necessary to make this framework work. By default, if the user does not specify the kind of the set, a `std::set` type is used.

##### Collection type of relation constraints

The constraints of the bimap set view are another very important feature. In general, Boost.Bimap users will base the set view type on one of the two collection types of their keys. It may be useful however to give this set other constraints or simply to order it differently. By default, Boost.Bimap bases the collection type of relations on the left collection type, but the user may choose between:

- left_based
- right_based
- set_of_relation<>
- multiset_of_relation<>
- unordered_set_of_relation<>
- unordered_multiset_of_relation<>
- list_of
- vector_of

In the first two cases, there are only two indices in the `multi_index_core`, and for this reason, these are the preferred options. The implementation uses further metaprogramming to define a new index if necessary.

##### Tagged

The idea of using tags instead of the `member_at::side` idiom is very appealing since code that uses it is more readable. The only cost is compile time. boost/bimap/tagged is the implementation of a non-invasive tagged idiom. The `relation` class is built in such a way that even when the user uses tags, the `member_at::side` idiom continues to work. This is good since an user can start tagging even before completing the coding of the algorithm, and the untagged code continues to work. The development becomes a little more complicated when user-defined tags are included, but there are many handy metafunctions defined in the `tagged` idiom that help to keep things simple enough.