Documentation fixes

doc/buckets.qbk

@@ -17,7 +17,7 @@ the hash function, `Hash`, to the element's key (for `unordered_set` and
 `unordered_multiset` the key is the whole element, but is referred to as the key
 so that the same terminology can be used for sets and maps). This returns a
 value of type `std::size_t`.  `std::size_t` has a much greater range of values
-then the number of buckets, so that container applies another transformation to
+then the number of buckets, so the container applies another transformation to
 that value to choose a bucket to place the element in.
 
 Retrieving the elements for a given key is simple. The same process is applied
@@ -57,7 +57,7 @@ keep collisions to a minimum.
       </row>
       <row>
         <entry>'''`size_type bucket(key_type const& k) const`'''</entry>
-        <entry>'''Returns the index of the bucket which would contain k'''</entry>
+        <entry>'''Returns the index of the bucket which would contain `k`.'''</entry>
       </row>
       <row>
         <entry>'''`local_iterator begin(size_type n);`'''</entry>
@@ -92,7 +92,7 @@ You can also tell the container to change the bucket count (if required) by
 calling `rehash`.
 
 The standard leaves a lot of freedom to the implementer to decide how the
-number of buckets are chosen, but it does make some requirements based on the
+number of buckets is chosen, but it does make some requirements based on the
 container's 'load factor', the average number of elements per bucket.
 Containers also have a 'maximum load factor' which they should try to keep the
 load factor below.
@@ -138,7 +138,7 @@ or close to the hint - unless your hint is unreasonably small or large.
     ]
     [
         [`void rehash(size_type n)`]
-        [Changes the number of buckets so that there at least n buckets, and
+        [Changes the number of buckets so that there at least `n` buckets, and
         so that the load factor is less than the maximum load factor.]
     ]
 
@@ -149,7 +149,7 @@ or close to the hint - unless your hint is unreasonably small or large.
 It is not specified how member functions other than `rehash` affect
 the bucket count, although `insert` is only allowed to invalidate iterators
 when the insertion causes the load factor to be greater than or equal to the
-maximum load factor. For most implementations this means that insert will only
+maximum load factor. For most implementations this means that `insert` will only
 change the number of buckets when this happens. While iterators can be
 invalidated by calls to `insert` and `rehash`, pointers and references to the
 container's elements are never invalidated.

doc/comparison.qbk

@@ -60,7 +60,7 @@
         [Iterators iterate through the container in the order defined by
             the comparison object.]
         [Iterators iterate through the container in an arbitrary order, that
-            can change as elements are inserted. Although, equivalent elements
+            can change as elements are inserted, although equivalent elements
             are always adjacent.]
     ]
     [

doc/compliance.qbk

@@ -4,7 +4,7 @@
 
 [section:compliance Standard Compliance]
 
-The intent of Boost.Unordered is to implement a close (but inperfect)
+The intent of Boost.Unordered is to implement a close (but imperfect)
 implementation of the C++17 standard, that will work with C++98 upwards.
 The wide compatibility does mean some comprimises have to be made.
 With a compiler and library that fully support C++11, the differences should
@@ -117,7 +117,7 @@ first part of the pair, and the remaining for the second part.
 
 When swapping, `Pred` and `Hash` are not currently swapped by calling
 `swap`, their copy constructors are used. As a consequence when swapping
-an exception may be throw from their  copy constructor.
+an exception may be thrown from their copy constructor.
 
 Variadic constructor arguments for `emplace` are only used when both
 rvalue references and variadic template parameters are available.

doc/intro.qbk

@@ -84,7 +84,7 @@ can be in any order. For example, it might be:
     one,1
     three,3
 
-To store an object in an unordered associative container requires both an
+To store an object in an unordered associative container requires both a
 key equality function and a hash function. The default function objects in
 the standard containers support a few basic types including integer types,
 floating point types, pointer types, and the standard strings. Since

doc/rationale.qbk

@@ -23,7 +23,7 @@ standard pretty much requires that the hash table uses chained addressing.
 
 It would be conceivable to write a hash table that uses another method.  For
 example, it could use open addressing, and use the lookup chain to act as a
-bucket but there are a some serious problems with this: 
+bucket but there are some serious problems with this:
 
 * The draft standard requires that pointers to elements aren't invalidated, so
   the elements can't be stored in one array, but will need a layer of
@@ -89,7 +89,7 @@ is that the required modulus operation is fairly expensive. This is what the
 containers do in most cases.
 
 Using a power of 2 allows for much quicker selection of the bucket
-to use, but at the expense of loosing the upper bits of the hash value.
+to use, but at the expense of losing the upper bits of the hash value.
 For some specially designed hash functions it is possible to do this and
 still get a good result but as the containers can take arbitrary hash
 functions this can't be relied on.