set_of Reference

namespace boost {
namespace bimap {


template
<
    class KeyType,
    class KeyCompare = std::less< KeyType >
>
struct set_of;


template
<
    class KeyCompare = std::less< _relation >
>
struct set_of_relation;


} // namespace bimap
} // namespace boost

Header "boost/bimap/multiset_of.hpp" synopsis

namespace boost {
namespace bimap {


template
<
    class KeyType,
    class KeyCompare = std::less< KeyType >
>
struct multiset_of;


template
<
    class KeyCompare = std::less< _relation >
>
struct multiset_of_relation;


} // namespace bimap
} // namespace boost

Set type specifiers set_of and multiset_of

These set type specifiers allow for insertion of sets disallowing or allowing duplicate elements, respectively. The syntaxes of set_of and multiset_of coincide, so they are described together.

[multi]set_of Views

Complexity signature
Instantiation types
Constructors, copy and assignment
Modifiers
Set operations
Range operations
operator[] - set_of only
Serialization

A [multi]set_of set view is a std::[multi]set signature-compatible interface to the underlying heap of elements contained in a bimap.

There are two variants: set_of, which does not allow duplicate elements (with respect to its associated comparison predicate) and multiset_of, which does accept those duplicates. The interface of these two variants is largely the same, so they are documented together with their differences explicitly noted where they exist.

If you look the bimap from a side, you will use a map view, and if you look at it as a whole, you will be using a set view.

namespace boost {
namespace bimap {
namespace views {

template< -implementation defined parameter list- >
class -implementation defined view name-
{
    public:

    typedef -unspecified- key_type;
    typedef -unspecified- value_type;
    typedef -unspecified- key_compare;
    typedef -unspecified- value_compare;
    typedef -unspecified- allocator_type;
    typedef -unspecified- reference;
    typedef -unspecified- const_reference;
    typedef -unspecified- iterator;
    typedef -unspecified- const_iterator;
    typedef -unspecified- size_type;
    typedef -unspecified- difference_type;
    typedef -unspecified- pointer;
    typedef -unspecified- const_pointer;
    typedef -unspecified- reverse_iterator;
    typedef -unspecified- const_reverse_iterator;

    this_type & operator=(const this_type & x);

    allocator_type get_allocator() const;

    // iterators

    iterator               begin();
    const_iterator         begin() const;
    iterator               end();
    const_iterator         end() const;
    reverse_iterator       rbegin();
    const_reverse_iterator rbegin() const;
    reverse_iterator       rend();
    const_reverse_iterator rend() const;

    // capacity

    bool      empty() const;
    size_type size() const;
    size_type max_size() const;

    // modifiers

    std::pair<iterator,bool> insert(const value_type& x);
    iterator insert(iterator position,const value_type& x);
    template<typename InputIterator>
    void insert(InputIterator first, InputIterator last);

    iterator  erase(iterator position);
    size_type erase(const key_type & x);
    iterator  erase(iterator first, iterator last);

    bool replace(iterator position, const value_type& x);
    template<typename Modifier> bool modify(iterator position, Modifier mod);
    template<typename Modifier> bool modify_key(iterator position, Modifier mod);

    void swap(this_type & x);
    void clear();

    // observers

    key_compare    key_comp() const;
    value_compare  value_comp() const;

    // set operations

    iterator find(const key_type & x) const;
    iterator find(const key_type & x, const key_type & comp) const;

    size_type count(const key_type & x) const;

    iterator lower_bound(const key_type & x) const;
    iterator lower_bound(const key_type & x, const key_type & comp) const;

    iterator upper_bound(const key_type & x) const;
    iterator upper_bound(const key_type & x, const key_type & comp) const;

    std::pair<iterator,iterator> equal_range(const key_type & x) const;

    std::pair<iterator,iterator> equal_range(
        const key_type & x, const key_type & comp) const;

    // range

    template<typename LowerBounder,typename UpperBounder>
    std::pair<iterator,iterator> range(
        LowerBounder lower, UpperBounder upper)const;

    // Only in a map view
    // {

    typedef -unspecified- data_type;

    const data_type & operator[](const typename key_type & k) const;
    -unspecified data_type proxy- operator[](const typename key_type & k);

    // }
};

// view comparison

bool operator==(const this_type & v1, const this_type & v2 );
bool operator< (const this_type & v1, const this_type & v2 );
bool operator!=(const this_type & v1, const this_type & v2 );
bool operator> (const this_type & v1, const this_type & v2 );
bool operator>=(const this_type & v1, const this_type & v2 );
bool operator<=(const this_type & v1, const this_type & v2 );

} // namespace views
} // namespace bimap
} // namespace boost

In the case of a bimap< {multi}set_of<Left>, ... >

In the set view:

typedef signature-compatible with relation<       Left, ... > key_type;
typedef signature-compatible with relation< const Left, ... > value_type;

In the left map view:

typedef  Left  key_type;
typedef  ...   data_type;

typedef signature-compatible with std::pair< const Left, ... > value_type;

In the right map view:

typedef  ...  key_type;
typedef  Left data_type;

typedef signature-compatible with std::pair< ... ,const Left > value_type;

Complexity signature

Here and in the descriptions of operations of this view, we adopt the scheme outlined in the complexity signature section. The complexity signature of [multi]set_of view is:

copying: c(n) = n * log(n),
insertion: i(n) = log(n),
hinted insertion: h(n) = 1 (constant) if the hint element precedes the point of insertion, h(n) = log(n) otherwise,
deletion: d(n) = 1 (amortized constant),
replacement: r(n) = 1 (constant) if the element position does not change, r(n) = log(n) otherwise,
modifying: m(n) = 1 (constant) if the element position does not change, m(n) = log(n) otherwise.

Instantiation types

Set views are instantiated internally to a bimap. Instantiations are dependent on the following types:

Value from the set specifier,
Allocator from bimap,
Compare from the set specifier.

Compare is a Strict Weak Ordering on elements of Value.

Constructors, copy and assignment

Set views do not have public constructors or destructors. Assignment, on the other hand, is provided.

this_type & operator=(const this_type & x);

Effects: a = b;
where a and b are the bimap objects to which *this and x belong, respectively.
Returns: *this.

Modifiers

std::pair<iterator,bool> insert(const value_type & x);

Effects: Inserts x into the bimap to which the set view belongs if
* the set view is non-unique OR no other element with equivalent key exists,
* AND insertion is allowed by the other set specifications the bimap.
Returns: The return value is a pair p. p.second is true if and only if insertion took place. On successful insertion, p.first points to the element inserted; otherwise, p.first points to an element that caused the insertion to be banned. Note that more than one element can be causing insertion not to be allowed.
Complexity: O(I(n)).
Exception safety: Strong.

iterator insert(iterator position, const value_type & x);

Requires: position is a valid iterator of the view.
Effects: Inserts x into the bimap to which the view belongs if
* the set view is non-unique OR no other element with equivalent key exists,
* AND insertion is allowed by all other views of the bimap.
position is used as a hint to improve the efficiency of the operation.
Returns: On successful insertion, an iterator to the newly inserted element. Otherwise, an iterator to an element that caused the insertion to be banned. Note that more than one element can be causing insertion not to be allowed.
Complexity: O(H(n)).
Exception safety: Strong.

template<typename InputIterator>
void insert(InputIterator first, InputIterator last);

Requires: InputIterator is a model of Input Iterator over elements of type value_type or a type convertible to value_type. first and last are not iterators into any view of the bimap to which this index belongs. last is reachable from first.
Effects:
iterator hint = end();
while( first != last ) hint = insert( hint, *first++ );
Complexity: O(m*H(n+m)), where m is the number of elements in [first, last).
Exception safety: Basic.

iterator erase(iterator position);

Requires: position is a valid dereferenceable iterator of the set view.
Effects: Deletes the element pointed to by position.
Returns: An iterator pointing to the element immediately following the one that was deleted, or end() if no such element exists.
Complexity: O(D(n)).
Exception safety: nothrow.

size_type erase(const key_type& x);

Effects: Deletes the elements with key equivalent to x.
Returns: Number of elements deleted.
Complexity: O(log(n) + m*D(n)), where m is the number of elements deleted.
Exception safety: Basic.

iterator erase(iterator first, iterator last);

Requires: [first,last) is a valid range of the view.
Effects: Deletes the elements in [first,last).
Returns: last.
Complexity: O(log(n) + m*D(n)), where m is the number of elements in [first,last).
Exception safety: nothrow.

bool replace(iterator position, const value_type& x);

Requires: position is a valid dereferenceable iterator of the set view.
Effects: Assigns the value x to the element pointed to by position into the bimap to which the set view belongs if, for the value x
* the set view is non-unique OR no other element with equivalent key exists (except possibly *position),
* AND replacing is allowed by all other set specifications of the bimap.
Postconditions: Validity of position is preserved in all cases.
Returns: true if the replacement took place, false otherwise.
Complexity: O(R(n)).
Exception safety: Strong. If an exception is thrown by some user-provided operation, the bimap to which the set view belongs remains in its original state.

template<typename Modifier> bool modify(iterator position, Modifier mod);

Requires: Modifier is a model of Binary Function accepting arguments of type:
Map View: first_type& and second_type&
Set View: left_type& and right_type&
position is a valid dereferenceable iterator of the view.
Effects:
Map View: Calls mod(e.first,e.second)
Set View: Calls mod(e.left,e.right)
where e is the element pointed to by position and rearranges *position into all the views of the bimap.
Rearrangement is successful if
* the view is non-unique OR no other element with equivalent key exists,
* AND rearrangement is allowed by all other views of the bimap.
If the rearrangement fails, the element is erased.
Postconditions: Validity of position is preserved if the operation succeeds.
Returns: true if the operation succeeded, false otherwise.
Complexity: O(M(n)).
Exception safety: Basic. If an exception is thrown by some user-provided operation (except possibly mod), then the element pointed to by position is erased.

Set operations

[multi]set_of views provide the full lookup functionality required by Sorted Associative Container and Unique Associative Container, namely find, count, lower_bound, upper_bound and equal_range. Additionally, these member functions are templatized to allow for non-standard arguments, so extending the types of search operations allowed. The kinds of arguments permissible when invoking the lookup member functions are defined by the following concept.

Consider a Strict Weak Ordering Compare over values of type Key. A pair of types (CompatibleKey, CompatibleCompare) is said to be a compatible extension of Compare if

CompatibleCompare is a Binary Predicate over (Key, CompatibleKey),
CompatibleCompare is a Binary Predicate over (CompatibleKey, Key),
if c_comp(ck,k1) then !c_comp(k1,ck),
if !c_comp(ck,k1) and !comp(k1,k2) then !c_comp(ck,k2),
if !c_comp(k1,ck) and !comp(k2,k1) then !c_comp(k2,ck),

for every c_comp of type CompatibleCompare, comp of type Compare, ck of type CompatibleKey and k1, k2 of type Key.

Additionally, a type CompatibleKey is said to be a compatible key of Compare if (CompatibleKey, Compare) is a compatible extension of Compare. This implies that Compare, as well as being a strict weak ordering, accepts arguments of type CompatibleKey, which usually means it has several overloads of operator().

In the context of a compatible extension or a compatible key, the expressions "equivalent", "less than" and "greater than" take on their obvious interpretations.

iterator find(const key_type & x) const;

Effects: Returns a pointer to an element whose key is equivalent to x, or end() if such an element does not exist.
Complexity: O(log(n)).

iterator find(const key_type & x, const key_type & comp) const;

Effects: Returns a pointer to an element whose key is equivalent to x, or end() if such an element does not exist.
Complexity: O(log(n)).

size_type count(const key_type & x) const;

Effects: Returns the number of elements with key equivalent to x.
Complexity: O(log(n) + count(x)).

iterator lower_bound(const key_type & x) const;

Effects: Returns an iterator pointing to the first element with key not less than x, or end() if such an element does not exist.
Complexity: O(log(n)).

iterator upper_bound(const key_type & x) const;

Effects: Returns an iterator pointing to the first element with key greater than x, or end() if such an element does not exist.
Complexity: O(log(n)).

std::pair<iterator,iterator> equal_range(const key_type & x) const;

Requires: CompatibleKey is a compatible key of key_compare.
Effects: Equivalent to make_pair(lower_bound(x),upper_bound(x)).
Complexity: O(log(n)).

Range operations

The member function range is not defined for sorted associative containers, but [multi]set_of views provide it as a convenient utility. A range or interval is defined by two conditions for the lower and upper bounds, which are modelled after the following concepts.

Consider a Strict Weak Ordering Compare over values of type Key. A type LowerBounder is said to be a lower bounder of Compare if

LowerBounder is a Predicate over Key,
if lower(k1) and !comp(k2,k1) then lower(k2),

for every lower of type LowerBounder, comp of type Compare, and k1, k2 of type Key. Similarly, an upper bounder is a type UpperBounder such that

UpperBounder is a Predicate over Key,
if upper(k1) and !comp(k1,k2) then upper(k2),

for every upper of type UpperBounder, comp of type Compare, and k1, k2 of type Key.

template<typename LowerBounder,typename UpperBounder>
std::pair<iterator,iterator> range(
    LowerBounder lower, UpperBounder upper) const;

Requires: LowerBounder and UpperBounder are a lower and upper bounder of key_compare, respectively.
Effects: Returns a pair of iterators pointing to the beginning and one past the end of the subsequence of elements satisfying lower and upper simultaneously. If no such elements exist, the iterators both point to the first element satisfying lower, or else are equal to end() if this latter element does not exist.
Complexity: O(log(n)).
Variants: In place of lower or upper (or both), the singular value boost::bimap::unbounded can be provided. This acts as a predicate which all values of type key_type satisfy.

operator[] - set_of only

The symmetry of bimap imposes some constraints on operator[] that are not found in std::maps. If other views are unique, bimap::duplicate_value is thrown whenever an assignment is attempted to a value that is already a key in these views. As for bimap::value_not_found, this exception is thrown while trying to access a non-existent key: this behaviour differs from that of std::map, which automatically assigns a default value to non-existent keys referred to by operator[].

const data_type & operator[](const typename key_type & k) const;

Effects: Returns the data_type reference that is associated with k, or throws bimap::value_not_found if such an element does not exist.
Complexity: O(log(n)).

-unspecified data_type proxy- operator[](const typename key_type & k);

Effects: Returns a proxy to a data_type associated with k and the bimap. The proxy behaves as a reference to the data_type object. If this proxy is read and k was not in the bimap, the bimap::value_not_found is thrown. If it is written then bimap::duplicate_value is thrown if the assignment is not allowed by one of the other views of the bimap.
Complexity: If the assignment operator of the proxy is not used, then the order is O(log(n)). If it is used, the order is O(I(n)) if k was not in the bimap and O(R(n)) if it existed in the bimap.

Serialization

Views cannot be serialized on their own, but only as part of the bimap into which they are embedded. In describing the additional preconditions and guarantees associated to [multi]set_of views with respect to serialization of their embedding containers, we use the concepts defined in the bimap serialization section.

Operation: saving of a bimap m to an output archive (XML archive) ar.

Requires: No additional requirements to those imposed by the container.

Operation: loading of a bimap m' from an input archive (XML archive) ar.

Requires: In addition to the general requirements, value_comp() must be serialization-compatible with m.get<i>().value_comp(), where i is the position of the ordered view in the container.
Postconditions: On successful loading, each of the elements of [begin(), end()) is a restored copy of the corresponding element in [m.get<i>().begin(), m.get<i>().end()).

Operation: saving of an iterator or const_iterator it to an output archive (XML archive) ar.

Requires: it is a valid iterator of the view. The associated bimap has been previously saved.

Operation: loading of an iterator or const_iterator it' from an input archive ( XML archive) ar.

Postconditions: On successful loading, if it was dereferenceable then *it' is the restored copy of *it, otherwise it' == end().
Note: It is allowed that it be a const_iterator and the restored it' an iterator, or viceversa.