From 29a0e5d163e1079a75fbdd2a03024cfebe3b97a9 Mon Sep 17 00:00:00 2001 From: Daniel James Date: Thu, 15 Nov 2007 23:36:33 +0000 Subject: [PATCH] Spell check the unordered container quickbook files. [SVN r41123] --- doc/buckets.qbk | 2 +- doc/comparison.qbk | 10 +++++----- doc/hash_equality.qbk | 2 +- doc/intro.qbk | 2 +- doc/rationale.qbk | 14 +++++++------- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/buckets.qbk b/doc/buckets.qbk index 9227acdb..a97ff93c 100644 --- a/doc/buckets.qbk +++ b/doc/buckets.qbk @@ -14,7 +14,7 @@ will have more buckets). In order to decide which bucket to place an element in, the container applies the hash function, `Hash`, to the element's key (for `unordered_set` and -`unordered_multiset` the key is the whole element, but is refered to as the key +`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 diff --git a/doc/comparison.qbk b/doc/comparison.qbk index f81a2392..360f6ab3 100644 --- a/doc/comparison.qbk +++ b/doc/comparison.qbk @@ -8,8 +8,8 @@ [[Associative Containers] [Unordered Associative Containers]] [ - [Parameterized by an ordering relation `Compare`] - [Parameterized by a function object `Hash` and an equivalence relation + [Parametrised by an ordering relation `Compare`] + [Parametrised by a function object `Hash` and an equivalence relation `Pred`] ] [ @@ -51,7 +51,7 @@ element can be inserted into a different bucket.] ] [ - [`iterator`, `const_iterator` are of the biderctional category.] + [`iterator`, `const_iterator` are of the bidirectional category.] [`iterator`, `const_iterator` are of at least the forward category.] ] [ @@ -108,7 +108,7 @@ ] [ [Insert a single element with a hint] - [Amortized constant if t elements inserted right after hint, + [Amortised constant if t elements inserted right after hint, logarithmic otherwise] [Average case constant, worst case linear (ie. the same as a normal insert).] @@ -125,7 +125,7 @@ ] [ [Erase a single element by iterator] - [Amortized constant] + [Amortised constant] [Average case: O(1), Worst case: O(`size()`)] ] [ diff --git a/doc/hash_equality.qbk b/doc/hash_equality.qbk index 86a46917..7569908c 100644 --- a/doc/hash_equality.qbk +++ b/doc/hash_equality.qbk @@ -68,7 +68,7 @@ Similarly, a custom hash function can be used for custom types: boost::unordered_multiset, point_hash> points; -Although, customizing Boost.Hash is probably a better solution: +Although, customising Boost.Hash is probably a better solution: struct point { int x; diff --git a/doc/intro.qbk b/doc/intro.qbk index 15cfed02..d594e5ee 100644 --- a/doc/intro.qbk +++ b/doc/intro.qbk @@ -28,7 +28,7 @@ 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 +or isn't practical. 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 diff --git a/doc/rationale.qbk b/doc/rationale.qbk index 81f5fd8a..563b57d0 100644 --- a/doc/rationale.qbk +++ b/doc/rationale.qbk @@ -16,7 +16,7 @@ The intent of this library is to implement the unordered containers in the draft standard, so the interface was fixed. But there are -still some implementation desicions to make. The priorities are +still some implementation decisions to make. The priorities are conformance to the standard and portability. The [@http://en.wikipedia.org/wiki/Hash_table wikipedia article on hash tables] @@ -46,7 +46,7 @@ bucket but there are a some serious problems with this: standard requires that it is initially set to 1.0. * And since the standard is written with a eye towards chained - addressing, users will be suprised if the performance doesn't reflect that. + addressing, users will be surprised if the performance doesn't reflect that. So chained addressing is used. @@ -76,9 +76,9 @@ There are two popular methods for choosing the number of buckets in a hash table. One is to have a prime number of buckets, another is to use a power of 2. -Using a prime number of buckets, and choosing a bucket by using the modulous -of the hash functions's result will usually give a good result. The downside -is that the required modulous operation is fairly expensive. +Using a prime number of buckets, and choosing a bucket by using the modulus +of the hash function's result will usually give a good result. The downside +is that the required modulus operation is fairly expensive. 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. @@ -91,7 +91,7 @@ example see __wang__. Unfortunately, a transformation like Wang's requires knowledge of the number of bits in the hash value, so it isn't portable enough. This leaves more expensive methods, such as Knuth's Multiplicative Method (mentioned in Wang's article). These don't tend to work as well as taking the -modulous of a prime, and the extra computation required might negate +modulus of a prime, and the extra computation required might negate efficiency advantage of power of 2 hash tables. So, this implementation uses a prime number for the hash table size. @@ -117,7 +117,7 @@ There is currently a further issue - if the allocator's swap does throw there's no guarantee what state the allocators will be in. The only solution seems to be to double buffer the allocators. But I'm assuming that it won't throw for now. -Update: The comittee have now decided that `swap` should do a fast swap if the +Update: The committee have now decided that `swap` should do a fast swap if the allocator is Swappable and a slow swap using copy construction otherwise. To make this distinction requires concepts. For now I'm sticking with the current implementation.