Fix mistakes (#84)

* Update index.html * Update basics.html * Update indices.html * Update debug.html * Update techniques.html * Update multi_index_container.html * Update indices.html * Update ord_indices.html * Update hash_indices.html * Update seq_indices.html * Update rnd_indices.html * Update key_extraction.html * Update compiler_specifics.html * Update performance.html * Update examples.html * Update tests.html * Update indices.html * Update key_extraction.html * Update key_extraction.html * Update multi_index_container.html * Update rnd_indices.html
2026-01-19 04:22:11 +00:00 · 2025-09-08 01:18:24 -07:00
parent 280d659bd9
commit c2aca0975e
16 changed files with 57 additions and 57 deletions
--- a/doc/compiler_specifics.html
+++ b/doc/compiler_specifics.html
@@ -263,7 +263,7 @@ by the compiler before doing any further type handling.
 </p>

 <p>
-Type hiding techniques can also be applied to <code>composite_key</code> intantiations,
+Type hiding techniques can also be applied to <code>composite_key</code> instantiations,
 which often contribute a great deal to symbol name lengths.
 </p>

@@ -274,7 +274,7 @@ Boost.MultiIndex support for legacy compilers is not actively kept, so if you ha
 to work with an old environment you might need to use a former version of the library.
 A table is provided of some legacy compilers along with the latest version of
 Boost.MultiIndex known to work for them (frequently with limitations as explained
-in the corresponding compiler specifics section.) If you successfully try one of those
+in the corresponding compiler specifics section). If you successfully try one of those
 with newer versions of Boost.MultiIndex than stated here, please report back so that
 the information can be updated. 
 </p>
--- a/doc/examples.html
+++ b/doc/examples.html
@@ -105,7 +105,7 @@ See <a href="../example/bimap.cpp">source code</a>.
 This example shows how to construct a bidirectional map with
 <code>multi_index_container</code>. By a <i>bidirectional map</i> we mean
 a container of <code>(const FromType,const ToType)</code> pairs
-such that no two elements exists with the same first
+such that no two elements exist with the same first
 <i>or</i> second component (<code>std::map</code> only
 guarantees uniqueness of the first component). Fast lookup is provided
 for both keys. The program features a tiny Spanish-English
--- a/doc/performance.html
+++ b/doc/performance.html
@@ -220,7 +220,7 @@ manual simulations.
 The gain in space consumption of <code>multi_index_container</code> with
 respect to its manual simulations is amenable to a very simple
 theoretical analysis. For simplicity, we will ignore alignment
-issues (which in general play in favor of <code>multi_index_container</code>.)
+issues (which in general play in favor of <code>multi_index_container</code>).
 </p>

 <p>
@@ -285,7 +285,7 @@ Taking this fact into account, the former formula can be adjusted to:

 <p>
 where <i>O</i> is the number of ordered indices of the container, and <i>w</i>
-is the system word size (typically 4 bytes on 32-bit architectures.)
+is the system word size (typically 4 bytes on 32-bit architectures).
 </p>

 <p>
@@ -473,7 +473,7 @@ sequenced index.</b>

 <p>
 The figures confirm that in this case <code>multi_index_container</code> nodes are the
-same size than those of its <code>std::list</code> counterpart.
+same size as those of its <code>std::list</code> counterpart.
 </p>

 <h4><a name="time_1s">Execution time</a></h4>
@@ -725,7 +725,7 @@ factor, which ranges from 45% to 55%.
 We have shown that <code>multi_index_container</code> outperforms, both in space and
 time efficiency, equivalent data structures obtained from the manual
 combination of STL containers. This improvement gets larger when the number
-of indices increase.
+of indices increases.
 </p>

 <p>
--- a/doc/reference/hash_indices.html
+++ b/doc/reference/hash_indices.html
@@ -199,7 +199,7 @@ together, with minor differences explicitly stated when they exist.
 <p>
 Except where noted or if the corresponding interface does not exist, hashed indices
 (both unique and non-unique) satisfy the C++ requirements for unordered associative
-containers at <b>[unord.req]</b> (supporting unique and equivalent keys, respectively.)
+containers at <b>[unord.req]</b> (supporting unique and equivalent keys, respectively).
 Iterators (including to the end of the index) and pointers and references to an element
 remain valid during the lifetime of the associated container (which can change
 upon swapping), or until the referred-to element is erased or extracted;
@@ -458,7 +458,7 @@ following types:
 which determines the mechanism for extracting a key from <code>Value</code>,
 must be a model of <a href="key_extraction.html#key_extractors">
 <code>Key Extractor</code></a> from <code>Value</code>. <code>Hash</code> is a
-<code>CopyConstructible</code>unary function object 
+<code>CopyConstructible</code> unary function object 
 taking a single argument of type <code>KeyFromValue::result_type</code> and returning a
 value of type <code>std::size_t</code> in the range
 <code>[0, std::numeric_limits&lt;std::size_t&gt;::max())</code>.
@@ -802,7 +802,7 @@ the number of elements in [<code>first</code>,<code>last</code>).<br>
 <code>position</code> is a valid dereferenceable iterator of the index.<br>
 <b>Effects:</b> Assigns the value <code>x</code> to the element pointed
 to by <code>position</code> into the <code>multi_index_container</code> to which
-the index belongs if, for the value <code>x</code>
+the index belongs if, for the value <code>x</code>,
 <ul>
  <li>the index is non-unique OR no other element exists
    (except possibly <code>*position</code>) with equivalent key,</li>
@@ -1355,7 +1355,7 @@ then <code>*it'</code> is the restored copy of <code>*it</code>; if <code>it</co
 was <code>m.get&lt;i&gt;().end(n)</code> for some <code>n</code>, then
 <code>it'==m'.get&lt;i&gt;().end(n)</code> (where <code>m</code> is the original
 <code>multi_index_container</code>, <code>m'</code> its restored copy
-and <code>i</code> is the ordinal of the index.)<br>
+and <code>i</code> is the ordinal of the index).<br>
 <b>Note:</b> It is allowed that <code>it</code> be a <code>const_local_iterator</code>
 and the restored <code>it'</code> a <code>local_iterator</code>, or vice versa.
 </blockquote>
--- a/doc/reference/indices.html
+++ b/doc/reference/indices.html
@@ -81,7 +81,7 @@ appropriate interface of some index of the <code>multi_index_container</code>;
 these operations, however, do have an impact on all other indices as
 well: for instance, insertion through a given index may fail because
 there exists another index which bans the operation in order to preserve
-its invariant (like uniqueness of elements.) This circumstance, rather
+its invariant (like uniqueness of elements). This circumstance, rather
 than being an obstacle, yields much of the power of Boost.MultiIndex:
 equivalent constructions based on manual composition of standard
 containers would have to add a fair amount of code in order to
@@ -103,7 +103,7 @@ six primitives:
 </ul>
 The last two primitives deserve some further explanation: in order to
 guarantee the invariants associated to each index (e.g. some definite
-ordering,) elements of a <code>multi_index_container</code> are not mutable.
+ordering), elements of a <code>multi_index_container</code> are not mutable.
 To overcome this restriction, indices expose member functions
 for replacement and modification which allow for the mutation of elements
 in a controlled fashion. Immutability of elements does not significantly
@@ -120,8 +120,8 @@ These global operations are not directly exposed to the user, but rather
 they are wrapped as appropriate by each index (for instance, ordered indices
 provide a set-like suite of insertion member functions, whereas sequenced
 and random access indices have <code>push_back</code> and <code>push_front</code>
-operations.) Boost.MultiIndex poses no particular conditions on
-the interface of indices, although each index provided satisfy the C++ requirements for
+operations). Boost.MultiIndex poses no particular conditions on
+the interface of indices, although each index provided satisfies the C++ requirements for
 standard containers to the maximum extent possible within the conceptual framework
 of the library.
 </p>
@@ -312,7 +312,7 @@ elements, as described in the <a href="key_extraction.html">key extraction
 reference</a>.
 <ul>
  <li><a href="ord_indices.html">Ordered indices</a> sort the elements
-    on the key and provide fast lookup capabilites.</li>
+    on the key and provide fast lookup capabilities.</li>
  <li><a href="rnk_indices.html">Ranked indices</a> are a variation of
    ordered indices providing extra operations based on 
    <i>rank</i>, the numerical position of an element
@@ -336,7 +336,7 @@ reference</a>.
 <h2><a name="views">Index views</a></h2>

 <p>
-The following concept is used by the rearrange facilities of non key-based
+The following concept is used by the rearrange facilities of non-key-based
 indices. Given an index <code>i</code> of type <code>Index</code>, a <i>view
 of <code>i</code></i> is any range [<code>first</code>,<code>last</code>)
 where <code>first</code> and <code>last</code> are input iterators such that
--- a/doc/reference/key_extraction.html
+++ b/doc/reference/key_extraction.html
@@ -776,7 +776,7 @@ lvalue reference to a non <code>const</code>-qualified type.
 <blockquote>
 <b>Requires:</b> <code>ChainedPtr</code> is a <a href="#chained_pointers">chained pointer</a>
 type to <code>Value</code>.<br>
-<b>Returns:</b> <code>PtrToFunction)(y)</code>, where <code>y</code> is the
+<b>Returns:</b> <code>PtrToFunction(y)</code>, where <code>y</code> is the
 object chained-pointed to by <code>x</code>.
 </blockquote>

@@ -1233,7 +1233,7 @@ bool operator <b><i>OP</i></b>(<br>

 <blockquote>
 <b>Requires:</b> The expressions given below are valid (for the particular
-<code><b><i>OP</i></b></code> considered.)<br>
+<code><b><i>OP</i></b></code> considered).<br>
 <b>Returns:</b> <code>true</code> if and only if
 <blockquote>
 <code>!(x==y)</code> (<code><b><i>OP</i></b></code> is <code>!=</code>),<br>
@@ -2078,7 +2078,7 @@ with respect to <code>composite_key_result&lt;CompositeKey></code>:
 <blockquote>
 <code>tuple&lt;Q0,...,Qj></code>,<br>
 <code>composite_key_result&lt;composite_key&lt;K0,...,Kj> ></code>, with
-<code>Ki::result_type = Qi</code> for all <code>i = 0,...,j</code>.
+<code>Ki::result_type = Qi</code> for all <code>i = 0,...,j</code>,
 </blockquote>
 provided that each <code>Qi</code> is either <code>Ti</code> or a
 <a href="hash_indices.html#lookup"><code>Compatible Key</code></a>
@@ -2097,9 +2097,9 @@ is lexicographical. Also, the following types are
 <code>composite_key_compare</code> with respect to
 <code>composite_key_result&lt;CompositeKey></code>:
 <blockquote>
-<code>tuple&lt;Q0,...,Qk></code>, <code>k &lt;= n</code><br>
+<code>tuple&lt;Q0,...,Qk></code>, <code>k &lt;= n</code>,<br>
 <code>composite_key_result&lt;composite_key&lt;K0,...,Kk> ></code>, with
-<code>Ki::result_type = Qi</code> for all <code>i = 0,...,k</code>.
+<code>Ki::result_type = Qi</code> for all <code>i = 0,...,k</code>,
 </blockquote>
 provided that 
 <ul>
@@ -2214,7 +2214,7 @@ and engenders undefined behavior otherwise. When passed two or more arguments,
 with:
 <ul>
  <li><code>KeyFromValuei</code> = <code>key&lt;Keyi&gt;</code>
-    for all <code>i = 0,...,n</code>
+    for all <code>i = 0,...,n</code>,
  </li>
  <li><code>Value</code> = <code>std::decay_t&lt;Value0&gt;</code> &#8855;
    <code>std::decay_t&lt;Value1&gt;</code>  &#8855; &middot;&middot;&middot;  &#8855;
--- a/doc/reference/multi_index_container.html
+++ b/doc/reference/multi_index_container.html
@@ -244,7 +244,7 @@ class.
 For convenience of use, all public methods and types of the first index
 specified are inherited by <code>multi_index_container</code>. This also includes global
 operators and functions associated with the index (vg. comparison and
-<code>swap</code>.)
+<code>swap</code>).
 </p>

 <blockquote><pre>
@@ -532,7 +532,7 @@ scheme outlined in the
  <li><code>IndexSpecifierList</code> specifies the indices that the
    <code>multi_index_container</code> is composed of. It must be a non-empty
    <a href="../../../../libs/mpl/doc/refmanual/forward-sequence.html">
-    <code>MPL Forward Sequence</code></a> (and, preferrably,
+    <code>MPL Forward Sequence</code></a> (and, preferably,
    an <a href="../../../../libs/mpl/doc/refmanual/random-access-sequence.html">
    <code>MPL Random Access Sequence</code></a>) of index specifiers. For
    syntactic convenience, the
@@ -738,7 +738,7 @@ multi_index_container(<br>
 <code>EmplaceConstructible</code> into <code>multi_index_container</code>
 from <code>*first</code>.
 <code>last</code> is reachable from <code>first</code>.<br> 
-<b>Effects:</b> Constructs and empty <code>multi_index_container</code> using the
+<b>Effects:</b> Constructs an empty <code>multi_index_container</code> using the
 specified argument list and allocator and fills it with
 the elements in the range [<code>first</code>,<code>last</code>).
 Insertion of each element may or may not succeed depending
@@ -765,7 +765,7 @@ the number of elements in [<code>first</code>,<code>last</code>).<br>
 <code>multi_index_container</code>.<br>
 <b>Effects:</b> Constructs a copy of <code>x</code>, copying its
 elements as well as its internal objects (those specified
-in <code>ctor_args_list</code> and the allocator.)<br>
+in <code>ctor_args_list</code> and the allocator).<br>
 <b>Postconditions:</b> <code>*this==x</code>. The order on every index
 of the <code>multi_index_container</code> is preserved as well.<br>
 <b>Complexity:</b> <code>O(x.size()*log(x.size()) + C(x.size()))</code>.
@@ -777,7 +777,7 @@ of the <code>multi_index_container</code> is preserved as well.<br>
 <blockquote>
 <b>Effects:</b> Constructs a <code>multi_index_container</code> by transferring the
 elements of <code>x</code> and copying its internal objects (those specified
-in <code>ctor_args_list</code> and the allocator.)<br>
+in <code>ctor_args_list</code> and the allocator).<br>
 <b>Postconditions:</b> If <code>x==y</code> just
 before the movement, <code>*this==y</code>. The order on every index
 of the <code>multi_index_container</code> is preserved as well.<br>
@@ -883,7 +883,7 @@ of the types of <code>ctor_args_list</code> do not throw.
 <blockquote>
 <b>Requires:</b> <code>Value</code> is <code>CopyInsertable</code> into
 <code>multi_index_container</code>.<br>
-<b>Effects:</b> Replaces the elements the <code>multi_index_container</code>
+<b>Effects:</b> Replaces the elements of the <code>multi_index_container</code>
 with copies of the elements of <code>list</code>, inserted in the specified order.
 Insertion of each element may or may not succeed depending
 on the acceptance by all the indices of the <code>multi_index_container</code>.<br>
@@ -965,7 +965,7 @@ typename nth_index&lt;N>::type::iterator project(IteratorType it);</code>
 <b>Requires:</b> <code>0 &lt;= N &lt; I-1</code>. <code>IteratorType</code>
 belongs to <code>iterator_type_list</code>. <code>it</code> is a valid
 iterator of some index of <code>*this</code> (i.e. does not refer to some
-other <code>multi_index_container</code>.)<br>
+other <code>multi_index_container</code>).<br>
 <b>Effects:</b> Returns an <code>nth_index&lt;N>::type::iterator</code> 
 equivalent to <code>it</code>.<br>
 <b>Complexity:</b> Constant.<br>
@@ -995,7 +995,7 @@ typename index&lt;Tag>::type::iterator project(IteratorType it);</code>
 <code>index&lt;Tag>::type</code> is valid. <code>IteratorType</code>
 belongs to <code>iterator_type_list</code>. <code>it</code> is a valid
 iterator of some index of <code>*this</code> (i.e. does not refer to some
-other <code>multi_index_container</code>.)<br>
+other <code>multi_index_container</code>).<br>
 <b>Effects:</b> Returns an <code>index&lt;Tag>::type::iterator</code>
 equivalent to <code>it</code>.<br>
 <b>Complexity:</b> Constant.<br>
@@ -1011,7 +1011,7 @@ typename index&lt;Tag>::type::const_iterator project(IteratorType it)const;</cod
 belongs to <code>const_iterator_type_list</code> or
 <code>iterator_type_list</code>. <code>it</code> is a valid
 (constant or non-constant) iterator of some index of <code>*this</code>
-(i.e. does not refer to some other <code>multi_index_container</code>.)<br>
+(i.e. does not refer to some other <code>multi_index_container</code>).<br>
 <b>Effects:</b> Returns an <code>index&lt;Tag>::type::const_iterator</code>
 iterator equivalent to <code>it</code>.<br>
 <b>Complexity:</b> Constant.<br>
@@ -1053,7 +1053,7 @@ output archive (XML archive) <code>ar</code>.

 <blockquote>
 <b>Requires:</b> <code>Value</code> is serializable (XML-serializable). Additionally,
-each of the indices of <code>m</code> can impose another requirements.<br>
+each of the indices of <code>m</code> can impose other requirements.<br>
 <b>Exception safety:</b> Strong with respect to <code>m</code>. If an exception
 is thrown, <code>ar</code> may be left in an inconsistent state.
 </blockquote>
@@ -1063,7 +1063,7 @@ input archive (XML archive) <code>ar</code>.

 <blockquote>
 <b>Requires:</b> <code>Value</code> is serializable (XML-serializable). Additionally,
-each of the indices of <code>m'</code> can impose another requirements.<br>
+each of the indices of <code>m'</code> can impose other requirements.<br>
 <b>Exception safety:</b> Basic. If an exception is thrown, <code>ar</code> may be
 left in an inconsistent state.
 </blockquote>
--- a/doc/reference/ord_indices.html
+++ b/doc/reference/ord_indices.html
@@ -196,7 +196,7 @@ together, with minor differences explicitly stated when they exist.
 Except where noted or if the corresponding interface does not exist,
 ordered indices (both unique and non-unique) satisfy the C++ requirements
 for associative containers at <b>[associative.reqmts]</b>
-(supporting unique and equivalent keys, respectively.)
+(supporting unique and equivalent keys, respectively).
 Iterators (including to the end of the index) and pointers and references to an element
 remain valid during the lifetime of the associated container (which can change
 upon swapping), or until the referred-to element is erased or extracted;
@@ -1324,7 +1324,7 @@ Operation: loading of an <code>iterator</code> or <code>const_iterator</code>
 then <code>*it'</code> is the restored copy of <code>*it</code>, otherwise
 <code>it'==end()</code>.<br>
 <b>Note:</b> It is allowed that <code>it</code> be a <code>const_iterator</code>
-and the restored <code>it'</code> an <code>iterator</code>, or viceversa.
+and the restored <code>it'</code> an <code>iterator</code>, or vice versa.
 </blockquote>

 <hr>
--- a/doc/reference/rnd_indices.html
+++ b/doc/reference/rnd_indices.html
@@ -178,7 +178,7 @@ plus the requirements for <code>std::list</code> specific list operations at
    have <code>data</code> member functions. 
  </li>

-  <li>The complexity of some operations, notably insertion and deletion, differ
+  <li>The complexities of some operations, notably insertion and deletion, differ
    from those of <code>std::vector</code>.
  </li>
  <li>Unlike as in <code>std::vector</code>, insertions into a random access index
@@ -439,7 +439,7 @@ of the complexity formulas:

 <p>
 (<code>shl</code> and <code>rel</code> stand for <i>shift left</i> and
-<i>relocate</i>, respectively.)
+<i>relocate</i>, respectively).
 </p>

 <h4><a name="instantiation_types">Instantiation types</a></h4>
@@ -550,7 +550,7 @@ const_iterator iterator_to(const value_type&amp; x)const;</code>
 <code>size()&lt;c</code>, back insertions happen in constant time (the
 general case as described by
 <a href="#complexity_signature"><code>i(n)</code></a> is <i>amortized</i>
-constant time.)<br>
+constant time).<br>
 <b>Note:</b> Validity of iterators and references to elements
 is preserved in all insertions, regardless of the capacity status.
 </blockquote>
@@ -590,7 +590,7 @@ into <code>multi_index_container</code>.<br>
 elements (first version) or copies of <code>x</code> (second version) at the end of
 the index. If <code>n&lt;size()</code>, erases the last <code>size()-n</code> elements.<br>
 <b>Note:</b> If an expansion is requested, the size of the index is not guaranteed
-to be <code>n</code> after this operation (other indices may ban insertions.)
+to be <code>n</code> after this operation (other indices may ban insertions).
 </blockquote>

 <h4><a name="modifiers">Modifiers</a></h4>
@@ -1223,7 +1223,7 @@ Operation: loading of an <code>iterator</code> or <code>const_iterator</code>
 then <code>*it'</code> is the restored copy of <code>*it</code>, otherwise
 <code>it'==end()</code>.<br>
 <b>Note:</b> It is allowed that <code>it</code> be a <code>const_iterator</code>
-and the restored <code>it'</code> an <code>iterator</code>, or viceversa.
+and the restored <code>it'</code> an <code>iterator</code>, or vice versa.
 </blockquote>

 <hr>
--- a/doc/reference/seq_indices.html
+++ b/doc/reference/seq_indices.html
@@ -525,7 +525,7 @@ into <code>multi_index_container</code>.<br>
 elements (first version) or copies of <code>x</code> (second version) at the end of
 the index. If <code>n&lt;size()</code>, erases the last <code>size()-n</code> elements.<br>
 <b>Note:</b> If an expansion is requested, the size of the index is not guaranteed
-to be <code>n</code> after this operation (other indices may ban insertions.)
+to be <code>n</code> after this operation (other indices may ban insertions).
 </blockquote>

 <h4><a name="modifiers">Modifiers</a></h4>
@@ -1158,7 +1158,7 @@ Operation: loading of an <code>iterator</code> or <code>const_iterator</code>
 then <code>*it'</code> is the restored copy of <code>*it</code>, otherwise
 <code>it'==end()</code>.<br>
 <b>Note:</b> It is allowed that <code>it</code> be a <code>const_iterator</code>
-and the restored <code>it'</code> an <code>iterator</code>, or viceversa.
+and the restored <code>it'</code> an <code>iterator</code>, or vice versa.
 </blockquote>

 <hr>
--- a/doc/tests.html
+++ b/doc/tests.html
@@ -55,7 +55,7 @@ with some of the least common features offered by Boost.MultiIndex.
 <tr>
  <td><a href="../test/test_capacity.cpp"><code>test_capacity.cpp</code></a></td>
  <td><code>empty</code>, <code>size</code>, <code>resize</code>
-  (non key-based indices) and <code>reserve</code>/<code>capacity</code>
+  (non-key-based indices) and <code>reserve</code>/<code>capacity</code>
  (random access indices only).</td>
 </tr>
 <tr class="odd_tr">
@@ -73,7 +73,7 @@ with some of the least common features offered by Boost.MultiIndex.
 <tr>
  <td><a href="../test/test_copy_assignment.cpp"><code>test_copy_assignment.cpp</code></a></td>
  <td>Various forms of assignment: copy, <code>operator =</code>, insertion,
-  (non key-based indices only) <code>assign</code> .
+  (non key-based indices only) <code>assign</code>.
 </tr>
 <tr class="odd_tr">
  <td><a href="../test/test_hash_ops.cpp"><code>test_hash_ops.cpp</code></a></td>
--- a/doc/tutorial/basics.html
+++ b/doc/tutorial/basics.html
@@ -114,7 +114,7 @@ construct easily becomes unmaintainable.
 <p>
 Boost.MultiIndex features <a href="#ord_indices"><i>ordered indices</i></a>, which
 sort the elements according to a particular key, and are designed to help programmers
-in need of sequences of elements for which <i>more than one</i> sorting criteria are
+in need of sequences of elements for which <i>more than one</i> sorting criterion is
 relevant. We do so by defining a <code>multi_index_container</code>
 instantiation composed of several ordered indices: each index, viewed in isolation,
 behaves much as an ordered <code>std::set</code> (or <code>std::multiset</code>), whilst
@@ -268,7 +268,7 @@ does not show any advantage. The code for inserting the text into the container
 does not change as sequenced indices provide an interface similar to that of
 <code>std::list</code> (no explicit access to this index through
 <code>get&lt;0>()</code> is needed as <code>multi_index_container</code> inherits the
-functionality of index #0.) But the specification of an additional ordered index
+functionality of index #0). But the specification of an additional ordered index
 allows us to implement <code>occurrences</code> and <code>delete_word</code>
 in a much more efficient manner:
 </p>
@@ -417,7 +417,7 @@ for instance,
  <li><code>employee_set::nth_index&lt;1>::type</code> is the type of
    index #1,</li>
  <li><code>employee_set::index&lt;name>::type</code> is the type of the index
-    tagged with <code>name</code> (the same index #1 in this case.)</li>
+    tagged with <code>name</code> (the same index #1 in this case).</li>
 </ul>
 <code>get()</code>, on the other hand, is overloaded to serve both styles of access:
 </p>
@@ -453,7 +453,7 @@ in the previous example can be rewritten to hold two different tags

 <p>
 Each index of a <code>multi_index_container</code> uses its own
-iterator types, which are different from those of another indices. As is
+iterator types, which are different from those of other indices. As is
 the rule with STL containers, these iterators are defined as nested
 types of the index:
 </p>
@@ -496,7 +496,7 @@ Currently, Boost.MultiIndex provides the following index types:
  <li>Ordered indices sort the elements like <code>std::set</code>s do and
    provide a similar interface. There are <i>unique</i> and <i>non-unique</i>
    variants: the former do not allow for duplicates, while the latter permit
-    them (like <code>std::multiset</code>.)</li>
+    them (like <code>std::multiset</code>).</li>
  <li>Ranked indices are a variation of ordered indices providing extra capabilities
    for querying and accessing elements based on their <i>rank</i> (the numerical position
    they occupy in the index).
@@ -766,7 +766,7 @@ Here we are not only passing IDs instead of <code>employee</code> objects:
 an alternative comparison predicate is passed as well. In general, lookup operations
 of ordered indices are overloaded to accept
 <a href="../reference/ord_indices.html#set_operations"><i>compatible sorting
-criteria</i></a>. The somewhat cumbersone definition of compatibility in this context
+criteria</i></a>. The somewhat cumbersome definition of compatibility in this context
 is given in the reference, but roughly speaking we say that a comparison predicate
 <code>C1</code> is compatible with <code>C2</code> if any sequence sorted by
 <code>C2</code> is also sorted with respect to <code>C1</code>.
@@ -801,7 +801,7 @@ The following shows a more interesting use of compatible predicates:
 Range searching, i.e. the lookup of all elements in a given interval, is a very
 frequent operation for which standard <code>lower_bound</code> and
 <code>upper_bound</code> can be resorted to, though in a cumbersome manner.
-For instance, the following code retrieves the elements of an
+For instance, the following code retrieves the elements of a
 <code>multi_index_container&lt;double></code> in the interval [100,200]:
 </p>

@@ -1229,7 +1229,7 @@ Appropriate instantiations of <code>multi_index_container</code> can in fact sim
 <code>std::set</code>, <code>std::multiset</code> and (with more limitations)
 <code>std::list</code>, as shown in the
 <a href="techniques.html#emulate_std_containers">techniques</a>
-section. These simulations are as nearly as efficient as the original STL
+section. These simulations are nearly as efficient as the original STL
 containers; consult the <a href="../reference/index.html">reference</a> for further
 information on complexity guarantees and the
 <a href="../performance.html">performance section</a> for practical measurements of
--- a/doc/tutorial/debug.html
+++ b/doc/tutorial/debug.html
@@ -162,7 +162,7 @@ asserting:
 </pre></blockquote>

 <p>
-Other possibilites, like outputting to a log or firing some kind of alert, are
+Other possibilities, like outputting to a log or firing some kind of alert, are
 also implementable.
 </p>

--- a/doc/tutorial/index.html
+++ b/doc/tutorial/index.html
@@ -101,7 +101,7 @@ indices are met.

 <p>
 All the public types of Boost.MultiIndex reside in namespace <code>::boost::multi_index</code>.
-Additionaly, the main class template <code>multi_index_container</code> and global functions
+Additionally, the main class template <code>multi_index_container</code> and global functions
 <code>get</code> and <code>project</code> are lifted to namespace <code>::boost</code>
 by means of <code>using</code> declarations. For brevity of exposition, the fragments
 of code in the documentation are written as if the following declarations were in effect:
--- a/doc/tutorial/indices.html
+++ b/doc/tutorial/indices.html
@@ -757,7 +757,7 @@ specifically designed for handling the elements of a container,
 and not only benefit from the iterator orientation of container interfaces,
 but are also capable of exposing many more programming bugs than raw pointers, both
 at compile and run time. <code>iterator_to</code> is thus meant to be used
-in scenarios where access via iterators is not suitable or desireable:
+in scenarios where access via iterators is not suitable or desirable:
 <ul>
  <li>Interoperability with preexisting APIs based on pointers or references.</li>
  <li>Publication of pointer-based interfaces (for instance, when
--- a/doc/tutorial/techniques.html
+++ b/doc/tutorial/techniques.html
@@ -53,7 +53,7 @@ Boost.MultiIndex reference
 containers</a></h3>

 <p>
-Academic movitations aside, there is a practical interest in emulating standard
+Academic motivations aside, there is a practical interest in emulating standard
 associative containers by means of <code>multi_index_container</code>, namely to take
 advantage of extended functionalities provided by <code>multi_index_container</code> for
 lookup, range querying and updating.