mirror of
https://github.com/boostorg/algorithm.git
synced 2025-07-29 12:07:18 +02:00
Some spelling errors fixed.
[SVN r23560]
This commit is contained in:
@ -25,7 +25,7 @@
|
||||
First requirement of string-type is that it must accessible using
|
||||
<link linkend="string_algo.collection_traits">collection traits</link>. This facility allows to access
|
||||
the elements inside the string in a uniform iterator-based fashion.
|
||||
This facility actualy requires lessen requirements then collection concept. It implements
|
||||
This facility actually requires lessen requirements then collection concept. It implements
|
||||
<ulink url="../../libs/algorithm/string/doc/external_concepts.html">external</ulink> collection interface.
|
||||
This is sufficient for our library
|
||||
</para>
|
||||
@ -36,9 +36,9 @@
|
||||
work even if this requirement will not be satisfied, however at the cost of performance degradation.
|
||||
<para>
|
||||
</para>
|
||||
In addition some algorithms have additional requirements on the string-type. Particulary, it is required,
|
||||
In addition some algorithms have additional requirements on the string-type. Particularly, it is required,
|
||||
that an algorithm can create a new string of the given type. In this case, it is required, that
|
||||
the type satifies the sequence (Std §23.1.1) requirements.
|
||||
the type satisfies the sequence (Std §23.1.1) requirements.
|
||||
</para>
|
||||
<para>
|
||||
In the reference and also in the code, requirement on the string type is designated by the name of
|
||||
@ -78,7 +78,7 @@
|
||||
and <code>end()</code> accessors, it has member functions for checking if the range is empty,
|
||||
or to determine the size of the range. It has also a set of member typedefs that extract
|
||||
type information from the encapsulated iterators. As such, the interface is compatible with
|
||||
the <link linkend="string_algo.collection_traits">collecion traits</link> requirements so
|
||||
the <link linkend="string_algo.collection_traits">collection traits</link> requirements so
|
||||
it is possible to use this class as a parameter to many algorithms in this library.
|
||||
</para>
|
||||
<para>
|
||||
@ -336,24 +336,24 @@
|
||||
|
||||
<para>
|
||||
The library provides some exceptions safety guaranties under following assumptions:
|
||||
<orderedlist numeration="arabic">
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
<para>
|
||||
All types that are used as a template arguments or passed as arguments to the
|
||||
facilities in this library provide <emphasis>basic exception guarantie</emphasis>.
|
||||
facilities in this library provide <emphasis>basic exception guarantee</emphasis>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
If the types mentioned in the first assumption can provide
|
||||
<emphasis>strong exception guarantie</emphasis> for their const operations, some algorithm
|
||||
<emphasis>strong exception guarantee</emphasis> for their const operations, some algorithm
|
||||
can provide stronger guaranties.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<para>
|
||||
Unless stated otherwise, all facilities and algorithms in this library have <emphasis>basic exception guarantie</emphasis>.
|
||||
Unless stated otherwise, all facilities and algorithms in this library have <emphasis>basic exception guarantee</emphasis>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
@ -409,7 +409,7 @@
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>find_all</entry>
|
||||
<entry>Find/Extract all matching substrings in hte input</entry>
|
||||
<entry>Find/Extract all matching substrings in the input</entry>
|
||||
<entry>
|
||||
<functionname>find_all()</functionname>
|
||||
<sbr/>
|
||||
|
@ -66,7 +66,7 @@
|
||||
<para><emphasis role="bold">Algorithm stacking:</emphasis>
|
||||
Copy versions return a transformed input as a result, thus allow a simple chaining of
|
||||
transformations within one expression (i.e. one can write <code>trim_copy(to_upper_copy(s))</code>).
|
||||
Mutable versions have <code>void</code> return, to avoid missuse.
|
||||
Mutable versions have <code>void</code> return, to avoid misuse.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -246,8 +246,8 @@
|
||||
|
||||
<para>
|
||||
An extension to find algorithms it the Find Iterator. Instead of searching for just a one part of a string,
|
||||
the find iterator allows us to iterate over the substrings matching the specified criterium.
|
||||
This facility is using the <link linkend="string_algo.finder_concept">Finder</link> to incrementaly
|
||||
the find iterator allows us to iterate over the substrings matching the specified criteria.
|
||||
This facility is using the <link linkend="string_algo.finder_concept">Finder</link> to incrementally
|
||||
search the string.
|
||||
Dereferencing a find iterator yields an <link linkend="string_algo.iterator_range"><code>iterator_range</code></link>
|
||||
object, that delimits the current match.
|
||||
@ -292,8 +292,8 @@
|
||||
<para>
|
||||
Note that find iterators have only one template parameter. It is the base iterator type.
|
||||
Finder is specified at runtime. This allows us to typedef a find iterator for
|
||||
a common string types and reuse it. Additionaly make_*_iterator functions helps
|
||||
to contruct a find iterator for a particular collection.
|
||||
a common string types and reuse it. Additionally make_*_iterator functions helps
|
||||
to construct a find iterator for a particular collection.
|
||||
</para>
|
||||
<para>
|
||||
See the reference in <headername>boost/algorithm/string/find_iterator.hpp</headername>.
|
||||
|
Reference in New Issue
Block a user