Being able to change the set type of the bimap relation view is another very important feature. Remember that this view allows the user to see the container as a group of the stored relations. This view has set semantics instead of map semantics.

By default, Boost.Bimap will base the set type of the relation on the type of the left set. If the left set type is a set, then the set type of the relation will be a set with the same order as the left view.

In general, Boost.Bimap users will base the set type of a relation on the type of the set on one of the two sides. However there are times where it is useful to give this set other constraints or simply to order it differently. The user is allowed to choose between:

The set type of relation can be used to create powerful containers. For example, if you need to maximize search speed, then the best bidirectional map possible is one that relates elements from an unordered_set to another unordered_set. The problem is that this container cannot be iterated. If you need to know the list of relations inside the container, you need another set type of relation. In this case, a list_of_relation is a good choice. The resulting container trades insertion and deletion time against fast search capabilities and the possibility of bidirectional iteration.

#include <iostream>
#include <string>
#include <boost/bimap/bimap.hpp>
#include <boost/bimap/list_of.hpp>
#include <boost/bimap/unordered_set_of.hpp>

struct english {};
struct spanish {};

int main()
{
    using namespace boost::bimap;

    typedef bimap
    <
        tagged< unordered_set_of< std::string >, spanish >,
        tagged< unordered_set_of< std::string >, english >
        list_of_relation

    > translator_bimap;

    typedef translator_bimap::relation translation;
    translator_bimap translator;
    translator.insert( translation("hola"  ,"hello"   ) );
    translator.insert( translation("adios" ,"goodbye" ) );
    translator.insert( translation("rosa"  ,"rose"    ) );
    translator.insert( translation("mesa"  ,"table"   ) );

    std::cout << "enter a word" << std::endl;
    std::string word;
    std::getline(std::cin,word);

    // Search the queried word on the from index (Spanish) */

    iterator_type_by<spanish,translator_bimap>::type is = map_by<spanish>(d).find(word);

    if( is != map_by<spanish>(d).end() )
    {
        std::cout << word << " is said " << get<english>(*is) << " in English" << std::endl;
    }
    else
    {
        // Word not found in Spanish, try our luck in English

        iterator_type_by<english,translator_bimap>::type ie = map_by<english>(d).find(word);
        if( ie != map_by<english>(d).end() )
        {
            std::cout << word << " is said " << get<spanish>(*ie) << " in Spanish" << std::endl;
        }
        else
        {
            // Word not found, show the possible translations

            std::cout << "No such word in the dictionary" << std::endl;
            std::cout << "These are the possible translations" << std::endl;
            for( translator_bimap::iterator i = translator.begin(), i_end = translator.end();
                 i != i_end ; ++i )
            {
                std::cout << get<spanish>(*i) << " <---> " << get<english>(*i) << std::endl;
            }
        }
    }
    return 0;
}

Configuration parameters

Each set type of relation has different parameters to control its behaviour. For example, in the set_of_relation specification, you can pass a Functor type that compares two types. All of the parameters are exactly as in the standard library containers, except for the type, which is set to the bimap relation and the allocator type. To help users in the creation of each functor, the set type of relation templates takes an mpl lambda expression where the relation type will be evaluated later. A placeholder named _relation is available to bimap users.

The following table lists the meaning of the parameters for each set type.

Examples

Consider this example:

template< class Rel >
struct RelOrder
{
    bool operator()(Rel ra, Rel rb)
    {
        return (ra.left+ra.right) < (rb.left+rb.right);
    }
};

typedef bimap
<
        multiset_of< int >,
        multiset_of< int >,
        set_of_relation< RelOrder<_relation> >

> bimap_type;

Here the bimap relation view is ordered using the information of both sides. This container will only allow unique relations because set_of_relation has been used but the elements in each side of the bimap can be repeated.

struct name         {};
struct phone_number {};

typedef bimap
<
    tagged< unordered_multiset_of< string >, name         >,
    tagged< unordered_set_of     < int    >, phone_number >,
    set_of_relation<>

> bimap_type;

In this other case the the bimap will relate names to phone numbers. Names can be repeated and phone numbers are unique. You can perform quick searches by name or phone number and the container can be viewed ordered using the relation view.