mirror of
https://github.com/boostorg/unordered.git
synced 2025-05-09 23:23:59 +00:00
df1e1598a5
Copyright update. Switch back to the version where the sentinel points to itself. Remove alternative versions of swap. Workaround a borland bug or two. More consistent use of class/swap/template. Avoid a few warnings. Add a no-throw swap to the allocator for exception testing. [SVN r3793]
99 lines
3.2 KiB
Plaintext
99 lines
3.2 KiB
Plaintext
[/ Copyright 2006-2007 Daniel James.
|
|
/ Distributed under the Boost Software License, Version 1.0. (See accompanying
|
|
/ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) ]
|
|
|
|
[def __tr1__
|
|
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2009.pdf
|
|
C++ Standard Library Technical Report]]
|
|
[def __draft__
|
|
[@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2009.pdf
|
|
Working Draft of the C++ Standard]]
|
|
[def __hash-table__ [@http://en.wikipedia.org/wiki/Hash_table
|
|
hash table]]
|
|
[def __hash-function__ [@http://en.wikipedia.org/wiki/Hash_function
|
|
hash function]]
|
|
|
|
[section:intro Introduction]
|
|
|
|
For accessing data based on keys, the C++ standard library offers `std::set`,
|
|
`std::map`, `std::multiset` and `std::multimap`. These are generally
|
|
implemented using balanced binary trees so lookup time has
|
|
logarithmic complexity. Which is generally okay, but in many cases a
|
|
__hash-table__ can perform better, as accessing data has constant complexity,
|
|
on average. The worst case complexity is linear, but that occurs rarely and
|
|
with some care, can be avoided.
|
|
|
|
Also, the existing containers require a 'less than' comparison object
|
|
to order their elements. For some data types this is impossible to implement
|
|
or isn't practicle. For a hash table you need an equality function
|
|
and a hash function for the key.
|
|
|
|
So the __tr1__ introduced the unordered associative containers, which are
|
|
implemented using hash tables, and they have now been added to the __draft__.
|
|
There are four containers to match the existing
|
|
associate containers. In the header <[headerref boost/unordered_set.hpp]>:
|
|
|
|
template <
|
|
class Key,
|
|
class Hash = boost::hash<Key>,
|
|
class Pred = std::equal_to<Key>,
|
|
class Alloc = std::allocator<Key> >
|
|
class ``[classref boost::unordered_set unordered_set]``;
|
|
|
|
template<
|
|
class Key,
|
|
class Hash = boost::hash<Key>,
|
|
class Pred = std::equal_to<Key>,
|
|
class Alloc = std::allocator<Key> >
|
|
class ``[classref boost::unordered_multiset unordered_multiset]``;
|
|
|
|
and in <[headerref boost/unordered_map.hpp]>:
|
|
|
|
template <
|
|
class Key, class T,
|
|
class Hash = boost::hash<Key>,
|
|
class Pred = std::equal_to<Key>,
|
|
class Alloc = std::allocator<Key> >
|
|
class ``[classref boost::unordered_map unordered_map]``;
|
|
|
|
template<
|
|
class Key, class T,
|
|
class Hash = boost::hash<Key>,
|
|
class Pred = std::equal_to<Key>,
|
|
class Alloc = std::allocator<Key> >
|
|
class ``[classref boost::unordered_multimap unordered_multimap]``;
|
|
|
|
The containers are used in a similar manner to the normal associative
|
|
containers:
|
|
|
|
#include <``[headerref boost/unordered_map.hpp]``>
|
|
#include <cassert>
|
|
|
|
int main()
|
|
{
|
|
boost::unordered_map<std::string, int> x;
|
|
x["one"] = 1;
|
|
x["two"] = 2;
|
|
x["three"] = 3;
|
|
|
|
assert(x["one"] == 1);
|
|
assert(x["missing"] == 0);
|
|
}
|
|
|
|
But since the elements aren't ordered, the output of:
|
|
|
|
BOOST_FOREACH(map::value_type i, x) {
|
|
std::cout<<i.first<<","<<i.second<<"\n";
|
|
}
|
|
|
|
can be in any order. For example, it might be:
|
|
|
|
two,2
|
|
one,1
|
|
three,3
|
|
missing,0
|
|
|
|
There are other differences, which will be detailed later.
|
|
|
|
[endsect]
|