
BoostCommit : 
From: daniel_james_at_[hidden]
Date: 20071115 18:36:35
Author: danieljames
Date: 20071115 18:36:33 EST (Thu, 15 Nov 2007)
New Revision: 41123
URL: http://svn.boost.org/trac/boost/changeset/41123
Log:
Spell check the unordered container quickbook files.
Text files modified:
sandbox/unordered/libs/unordered/doc/buckets.qbk  2 +
sandbox/unordered/libs/unordered/doc/comparison.qbk  10 +++++
sandbox/unordered/libs/unordered/doc/hash_equality.qbk  2 +
sandbox/unordered/libs/unordered/doc/intro.qbk  2 +
sandbox/unordered/libs/unordered/doc/rationale.qbk  14 +++++++
5 files changed, 15 insertions(+), 15 deletions()
Modified: sandbox/unordered/libs/unordered/doc/buckets.qbk
==============================================================================
 sandbox/unordered/libs/unordered/doc/buckets.qbk (original)
+++ sandbox/unordered/libs/unordered/doc/buckets.qbk 20071115 18:36:33 EST (Thu, 15 Nov 2007)
@@ 14,7 +14,7 @@
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
Modified: sandbox/unordered/libs/unordered/doc/comparison.qbk
==============================================================================
 sandbox/unordered/libs/unordered/doc/comparison.qbk (original)
+++ sandbox/unordered/libs/unordered/doc/comparison.qbk 20071115 18:36:33 EST (Thu, 15 Nov 2007)
@@ 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()`)]
]
[
Modified: sandbox/unordered/libs/unordered/doc/hash_equality.qbk
==============================================================================
 sandbox/unordered/libs/unordered/doc/hash_equality.qbk (original)
+++ sandbox/unordered/libs/unordered/doc/hash_equality.qbk 20071115 18:36:33 EST (Thu, 15 Nov 2007)
@@ 68,7 +68,7 @@
boost::unordered_multiset<point, std::equal_to<point>, 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;
Modified: sandbox/unordered/libs/unordered/doc/intro.qbk
==============================================================================
 sandbox/unordered/libs/unordered/doc/intro.qbk (original)
+++ sandbox/unordered/libs/unordered/doc/intro.qbk 20071115 18:36:33 EST (Thu, 15 Nov 2007)
@@ 28,7 +28,7 @@
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
Modified: sandbox/unordered/libs/unordered/doc/rationale.qbk
==============================================================================
 sandbox/unordered/libs/unordered/doc/rationale.qbk (original)
+++ sandbox/unordered/libs/unordered/doc/rationale.qbk 20071115 18:36:33 EST (Thu, 15 Nov 2007)
@@ 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 @@
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 @@
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 @@
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 @@
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.
BoostCommit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk