diff --git a/doc/compiler_specifics.html b/doc/compiler_specifics.html index f5c3492..5fac2d7 100644 --- a/doc/compiler_specifics.html +++ b/doc/compiler_specifics.html @@ -263,7 +263,7 @@ by the compiler before doing any further type handling.

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

@@ -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.

diff --git a/doc/examples.html b/doc/examples.html index 5101b37..7afd352 100644 --- a/doc/examples.html +++ b/doc/examples.html @@ -105,7 +105,7 @@ See source code. This example shows how to construct a bidirectional map with multi_index_container. By a bidirectional map we mean a container of (const FromType,const ToType) pairs -such that no two elements exists with the same first +such that no two elements exist with the same first or second component (std::map only guarantees uniqueness of the first component). Fast lookup is provided for both keys. The program features a tiny Spanish-English diff --git a/doc/performance.html b/doc/performance.html index 64819e8..ead41ec 100644 --- a/doc/performance.html +++ b/doc/performance.html @@ -220,7 +220,7 @@ manual simulations. The gain in space consumption of multi_index_container 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 multi_index_container.) +issues (which in general play in favor of multi_index_container).

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

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

@@ -473,7 +473,7 @@ sequenced index.

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

Execution time

@@ -725,7 +725,7 @@ factor, which ranges from 45% to 55%. We have shown that multi_index_container 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.

diff --git a/doc/reference/hash_indices.html b/doc/reference/hash_indices.html index d847205..3332bb9 100644 --- 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.

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 [unord.req] (supporting unique and equivalent keys, respectively.) +containers at [unord.req] (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 Value, must be a model of Key Extractor from Value. Hash is a -CopyConstructibleunary function object +CopyConstructible unary function object taking a single argument of type KeyFromValue::result_type and returning a value of type std::size_t in the range [0, std::numeric_limits<std::size_t>::max()). @@ -802,7 +802,7 @@ the number of elements in [first,last).
position is a valid dereferenceable iterator of the index.
Effects: Assigns the value x to the element pointed to by position into the multi_index_container to which -the index belongs if, for the value x +the index belongs if, for the value x,

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 multi_index_container are not mutable. +ordering), elements of a multi_index_container 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 push_back and push_front -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.

@@ -312,7 +312,7 @@ elements, as described in the key extraction reference. get(), on the other hand, is overloaded to serve both styles of access:

@@ -453,7 +453,7 @@ in the previous example can be rewritten to hold two different tags

Each index of a multi_index_container 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:

@@ -496,7 +496,7 @@ Currently, Boost.MultiIndex provides the following index types:
  • Ordered indices sort the elements like std::sets do and provide a similar interface. There are unique and non-unique variants: the former do not allow for duplicates, while the latter permit - them (like std::multiset.)
    • + them (like std::multiset).
  • Ranked indices are a variation of ordered indices providing extra capabilities for querying and accessing elements based on their rank (the numerical position they occupy in the index). @@ -766,7 +766,7 @@ Here we are not only passing IDs instead of employee objects: an alternative comparison predicate is passed as well. In general, lookup operations of ordered indices are overloaded to accept compatible sorting -criteria. The somewhat cumbersone definition of compatibility in this context +criteria. The somewhat cumbersome definition of compatibility in this context is given in the reference, but roughly speaking we say that a comparison predicate C1 is compatible with C2 if any sequence sorted by C2 is also sorted with respect to C1. @@ -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 lower_bound and upper_bound 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 multi_index_container<double> in the interval [100,200]:

    @@ -1229,7 +1229,7 @@ Appropriate instantiations of multi_index_container can in fact sim std::set, std::multiset and (with more limitations) std::list, as shown in the techniques -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 reference for further information on complexity guarantees and the performance section for practical measurements of diff --git a/doc/tutorial/debug.html b/doc/tutorial/debug.html index ce86655..7cfb231 100644 --- a/doc/tutorial/debug.html +++ b/doc/tutorial/debug.html @@ -162,7 +162,7 @@ asserting:

    -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.

    diff --git a/doc/tutorial/index.html b/doc/tutorial/index.html index b70ea35..16cf25d 100644 --- a/doc/tutorial/index.html +++ b/doc/tutorial/index.html @@ -101,7 +101,7 @@ indices are met.

    All the public types of Boost.MultiIndex reside in namespace ::boost::multi_index. -Additionaly, the main class template multi_index_container and global functions +Additionally, the main class template multi_index_container and global functions get and project are lifted to namespace ::boost by means of using declarations. For brevity of exposition, the fragments of code in the documentation are written as if the following declarations were in effect: diff --git a/doc/tutorial/indices.html b/doc/tutorial/indices.html index dee316e..987a402 100644 --- 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. iterator_to 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: