mirror of
https://github.com/boostorg/range.git
synced 2025-06-28 05:20:59 +02:00
Compare commits
5 Commits
svn-branch
...
boost-1.33
| Author | SHA1 | Date | |
|---|---|---|---|
| 7245a2dfc1 | |||
| 9b66041b25 | |||
| b4f01b66bb | |||
| 59f118601a | |||
| d0f9bf8cc0 |
@ -46,14 +46,19 @@
|
||||
<li >
|
||||
null terminated strings (this includes <code >char[]</code>,<code >wchar_t[]</code>,
|
||||
<code >char*</code>, and <code >wchar_t*</code>)
|
||||
<p>
|
||||
<b>Warning:</b><i> support for null-terminated strings is deprecated and will
|
||||
disappear in the next Boost release (1.34). </i>
|
||||
</p>
|
||||
|
||||
</li>
|
||||
<li >
|
||||
built-in arrays
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
Even though the behavior of the primary templates are exactly such that standard
|
||||
containers will be supported by default, the requirements are much lower than
|
||||
Even though the behavior of the primary templates are exactly such that standard
|
||||
containers will be supported by default, the requirements are much lower than
|
||||
the standard container requirements. For example, the utility class <a
|
||||
href="utility_class.html#iter_range"><code>iterator_range</code></a> implements
|
||||
the <a href="#minimal_interface">minimal interface</a> required to make the
|
||||
@ -287,7 +292,7 @@ class=identifier>T</span><span class=special>& </span><span class=identifier
|
||||
<td ><code >range_difference<X>::type</code></td>
|
||||
<td ><code >T::difference_type</code><br>
|
||||
<code
|
||||
>boost_iterator_difference<P::first_type>::type</code><br>
|
||||
>boost::iterator_difference<P::first_type>::type</code><br>
|
||||
<code >std::ptrdiff_t</code><br>
|
||||
<code >std::ptrdiff_t</code><br>
|
||||
<td >compile time</td>
|
||||
|
||||
@ -24,8 +24,13 @@
|
||||
<li >
|
||||
<a href="../test/string.cpp" target="_self" ><code >string.cpp</code></a>
|
||||
</li>
|
||||
shows how to implement a container version of <code >std::find()</code> that
|
||||
shows how to implement a container version of <code >std::find()</code> that
|
||||
works with <code >char[],wchar_t[],char*,wchar_t*.</code>
|
||||
<p>
|
||||
<b>Warning:</b><i> support for null-terminated strings is deprecated and will
|
||||
disappear in the next Boost release (1.34). </i>
|
||||
</p>
|
||||
|
||||
<li >
|
||||
<a href="../test/algorithm_example.cpp" target="_self" ><code >algorithm_example.cpp</code></a>
|
||||
|
||||
|
||||
76
doc/faq.html
76
doc/faq.html
@ -20,36 +20,36 @@
|
||||
<h2 >FAQ</h2> <a name="FAQ" ></a>
|
||||
<ol >
|
||||
<li >
|
||||
<i>Why is there no difference between <code >range_iterator<C>::type</code>
|
||||
<i>Why is there no difference between <code >range_iterator<C>::type</code>
|
||||
and <code >range_const_iterator<C>::type</code> for <code>std::pair<iterator, iterator></code></i>.
|
||||
</li>
|
||||
<p >
|
||||
In general it is not possible nor desirable to find a corresponding <code >const_iterator</code>.
|
||||
When it is possible to come up with one, the client might choose to construct a <code >std::pair<const_iterator,const_iterator></code>
|
||||
In general it is not possible nor desirable to find a corresponding <code >const_iterator</code>.
|
||||
When it is possible to come up with one, the client might choose to construct a <code >std::pair<const_iterator,const_iterator></code>
|
||||
object.
|
||||
</p>
|
||||
<p>
|
||||
Note that an <a href="utility_class.html#iter_range">iterator_range</a>
|
||||
is somewhat more convenient than a <code>pair</code> and that a <a
|
||||
href="utility_class.html#sub_range"><code>sub_range</code></a> do
|
||||
Note that an <a href="utility_class.html#iter_range">iterator_range</a>
|
||||
is somewhat more convenient than a <code>pair</code> and that a <a
|
||||
href="utility_class.html#sub_range"><code>sub_range</code></a> does
|
||||
propagate const-ness. </p>
|
||||
|
||||
|
||||
<li >
|
||||
<i>Why is there not supplied more types or more functions?</i>
|
||||
<p >
|
||||
The library has been kept small because its current interface will
|
||||
The library has been kept small because its current interface will
|
||||
serve most
|
||||
purposes. If and when a genuine need arises for more functionality, it can be
|
||||
purposes. If and when a genuine need arises for more functionality, it can be
|
||||
implemented.
|
||||
</p>
|
||||
</li>
|
||||
<li >
|
||||
<i>How should I implement generic algorithms for ranges?</i>
|
||||
<p >
|
||||
One should always start with a generic algorithm that takes two iterators (or
|
||||
more) as input. Then use Boost.Range to build handier versions on top of the
|
||||
iterator based algorithm. Please notice that once the range version of the
|
||||
algorithm is done, it makes sense <i>not</i> to expose the iterator version in
|
||||
One should always start with a generic algorithm that takes two iterators (or
|
||||
more) as input. Then use Boost.Range to build handier versions on top of the
|
||||
iterator based algorithm. Please notice that once the range version of the
|
||||
algorithm is done, it makes sense <i>not</i> to expose the iterator version in
|
||||
the public interface.
|
||||
</p>
|
||||
</li>
|
||||
@ -57,59 +57,59 @@
|
||||
<i>Why is there no Incrementable Range concept?</i>
|
||||
<p>
|
||||
Even though we speak of incrementable iterators, it would not make
|
||||
much sense for ranges; for example, we cannot determine the size and
|
||||
emptiness of a range since we cannot even compare
|
||||
its iterators.
|
||||
much sense for ranges; for example, we cannot determine the size and
|
||||
emptiness of a range since we cannot even compare
|
||||
its iterators.
|
||||
</p>
|
||||
<p>
|
||||
Note also that incrementable iterators are derived from output
|
||||
Note also that incrementable iterators are derived from output
|
||||
iterators and so there exist no output range.
|
||||
</p>
|
||||
</li>
|
||||
</li>
|
||||
<!--
|
||||
<li>
|
||||
<i>Should I use qualified syntax, for example
|
||||
<blockquote><pre>
|
||||
<span class=identifier>boost</span><span class=special>::</span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>r </span><span class=special>); </span>
|
||||
</pre></blockquote>
|
||||
instead of
|
||||
instead of
|
||||
<blockquote>
|
||||
<pre><span class=keyword>using </span><span class=keyword>namespace </span><span class=identifier>boost</span><span class=special>;</span>
|
||||
<span class=identifier>begin</span><span class=special>( </span><span class=identifier>r </span><span class=special>)</span></pre></blockquote>
|
||||
when calling functions in this library? If so, can I still rely on argument
|
||||
when calling functions in this library? If so, can I still rely on argument
|
||||
dependent lookup (ADL) to kick in?</i>
|
||||
<p>
|
||||
The answer to the first question is that "it's up to you". The
|
||||
answer to the second question is Yes. Normally qualified syntax
|
||||
disables ADL, but the functions are implemented in a special
|
||||
manner that preserves ADL properties. The trick was explained by
|
||||
Daniel Frey on comp.lang.std.c++ in the thread "Whence Swap" and
|
||||
The answer to the first question is that "it's up to you". The
|
||||
answer to the second question is Yes. Normally qualified syntax
|
||||
disables ADL, but the functions are implemented in a special
|
||||
manner that preserves ADL properties. The trick was explained by
|
||||
Daniel Frey on comp.lang.std.c++ in the thread "Whence Swap" and
|
||||
it is best explained by some code: <blockquote>
|
||||
<pre>
|
||||
<span class=keyword>namespace </span><span class=identifier>boost</span>
|
||||
<span class=special>{
|
||||
</span><span class=keyword>namespace </span><span class=identifier>range_detail
|
||||
</span><span class=keyword>namespace </span><span class=identifier>range_detail
|
||||
</span><span class=special>{
|
||||
</span><span class=keyword>template</span><span class=special>< </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>>
|
||||
</span><span class=keyword>template</span><span class=special>< </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>>
|
||||
</span><span class=keyword>typename </span><span class=identifier>range_iterator</span><span class=special><</span><span class=identifier>T</span><span class=special>>:</span><span class=identifier>type </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>T</span><span class=special>& </span><span class=identifier>r </span><span class=special>)
|
||||
</span><span class=special>{ </span><span class=comment>/* normal implementation */ </span><span class=special>}
|
||||
</span><span class=special>}
|
||||
|
||||
</span><span class=keyword>template</span><span class=special>< </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>>
|
||||
</span><span class=special>}
|
||||
|
||||
</span><span class=keyword>template</span><span class=special>< </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>>
|
||||
</span><span class=keyword>typename </span><span class=identifier>range_iterator</span><span class=special><</span><span class=identifier>T</span><span class=special>>::</span><span class=identifier>type </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>T</span><span class=special>& </span><span class=identifier>r </span><span class=special>)
|
||||
</span><span class=special>{
|
||||
</span><span class=comment>//
|
||||
</span><span class=comment>//
|
||||
// Create ADL hook
|
||||
//
|
||||
</span><span class=keyword>using </span><span class=identifier>range_detail</span><span class=special>::</span><span class=identifier>begin</span><span class=special>;
|
||||
</span><span class=keyword>return </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>r </span><span class=special>);
|
||||
//
|
||||
</span><span class=keyword>using </span><span class=identifier>range_detail</span><span class=special>::</span><span class=identifier>begin</span><span class=special>;
|
||||
</span><span class=keyword>return </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>r </span><span class=special>);
|
||||
</span><span class=special>}</span>
|
||||
<span class=special>} </span>
|
||||
<span class=special>} </span>
|
||||
</pre>
|
||||
</blockquote>
|
||||
Cool indeed!
|
||||
</blockquote>
|
||||
Cool indeed!
|
||||
</p>
|
||||
-->
|
||||
-->
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
@ -18,36 +18,36 @@
|
||||
|
||||
<h2>Introduction</h2>
|
||||
<p>
|
||||
Generic algorithms have so far been specified in terms of two or more
|
||||
iterators. Two iterators would together form a range of values that the
|
||||
Generic algorithms have so far been specified in terms of two or more
|
||||
iterators. Two iterators would together form a range of values that the
|
||||
algorithm could work on. This leads to a very general interface, but also
|
||||
to a somewhat clumsy use of the algorithms with redundant specification
|
||||
of container names. Therefore we would like to raise the abstraction level
|
||||
for algorithms so they specify their interface in terms of <a
|
||||
for algorithms so they specify their interface in terms of <a
|
||||
href=range.html>Ranges</a> as much as possible.
|
||||
</p>
|
||||
|
||||
|
||||
<p>
|
||||
The most common form of ranges we are used to work with is standard library
|
||||
The most common form of ranges we are used to work with is standard library
|
||||
containers. However, one
|
||||
often finds it desirable to extend that code to work with other types that
|
||||
often finds it desirable to extend that code to work with other types that
|
||||
offer
|
||||
enough functionality to satisfy the needs of the generic code
|
||||
<i>if a suitable layer of indirection is applied </i>. For
|
||||
enough functionality to satisfy the needs of the generic code
|
||||
<i>if a suitable layer of indirection is applied </i>. For
|
||||
example, raw arrays are often suitable for use with generic code that
|
||||
works with containers, provided a suitable adapter is used. Likewise, null
|
||||
terminated strings can be treated as containers of characters, if suitably
|
||||
adapted.
|
||||
</p>
|
||||
|
||||
works with containers, provided a suitable adapter is used. Likewise, null
|
||||
terminated strings can be treated as containers of characters, if suitably
|
||||
adapted.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
This library therefore provides the means to adapt standard-like
|
||||
This library therefore provides the means to adapt standard-like
|
||||
containers,
|
||||
null terminated strings, <code>std::pairs</code> of iterators, and raw
|
||||
arrays (and more), such that the same generic code can work with them all.
|
||||
The basic idea is to add another layer of indirection using <a
|
||||
href="../../mpl/doc/index.html#metafunctions">metafunctions</a> and
|
||||
free-standing functions so syntactic and/or semantic differences can be removed.
|
||||
null terminated strings, <code>std::pairs</code> of iterators, and raw
|
||||
arrays (and more), such that the same generic code can work with them all.
|
||||
The basic idea is to add another layer of indirection using <a
|
||||
href="../../mpl/doc/refmanual/metafunction.html">metafunctions</a> and
|
||||
free-standing functions so syntactic and/or semantic differences can be removed.
|
||||
</p>
|
||||
|
||||
<p >
|
||||
@ -61,15 +61,19 @@ free-standing functions so syntactic and/or semantic differences can be removed.
|
||||
</li>
|
||||
<li >
|
||||
correct handling of null-terminated strings
|
||||
<p>
|
||||
<b>Warning:</b><i> support for null-terminated strings is deprecated and will
|
||||
disappear in the next Boost release (1.34). </i>
|
||||
</p>
|
||||
</li>
|
||||
<li >
|
||||
safe use of built-in arrays (for legacy code; why else would you use
|
||||
safe use of built-in arrays (for legacy code; why else would you use
|
||||
built-in arrays?) </li>
|
||||
|
||||
</ul>
|
||||
</p>
|
||||
<p >
|
||||
Below are given a small example (the complete example can be found <a href="../test/algorithm_example.cpp" target="_self" >here</a>
|
||||
Below are given a small example (the complete example can be found <a href="../test/algorithm_example.cpp" target="_self" >here</a>
|
||||
):
|
||||
<blockquote>
|
||||
<pre >
|
||||
@ -130,7 +134,7 @@ class=identifier>assign</span><span class=special>( </span><span class=identifie
|
||||
</blockquote>
|
||||
|
||||
By using the free-standing functions and <a
|
||||
href="../../mpl/doc/index.html#metafunctions">metafunctions</a>, the code automatically
|
||||
href="../../mpl/doc/refmanual/metafunction.html">metafunctions</a>, the code automatically
|
||||
works for all the types supported by this library; now and in the future.
|
||||
Notice that we have to
|
||||
provide two version of <code >find()</code> since we cannot forward a non-const
|
||||
|
||||
148
doc/range.html
148
doc/range.html
@ -44,16 +44,16 @@
|
||||
|
||||
<p>
|
||||
A Range is a <i>concept</i> similar to the STL <a
|
||||
href="http://www.sgi.com/Technology/STL/Container.html">Container</a> concept. A
|
||||
href="http://www.sgi.com/Technology/STL/Container.html">Container</a> concept. A
|
||||
Range provides iterators for accessing a half-open range
|
||||
<code>[first,one_past_last)</code> of elements and provides
|
||||
information about the number of elements in the Range. However, a Range has
|
||||
fewer requirements than a Container.
|
||||
</p>
|
||||
information about the number of elements in the Range. However, a Range has
|
||||
fewer requirements than a Container.
|
||||
</p>
|
||||
<p>
|
||||
The motivation for the Range concept is
|
||||
that there are many useful Container-like types that do not meet the full
|
||||
requirements of Container, and many algorithms that can be written with this
|
||||
The motivation for the Range concept is
|
||||
that there are many useful Container-like types that do not meet the full
|
||||
requirements of Container, and many algorithms that can be written with this
|
||||
reduced set of requirements. In particular, a Range does not necessarily
|
||||
|
||||
<ul>
|
||||
@ -67,25 +67,25 @@
|
||||
-->
|
||||
</ul>
|
||||
|
||||
|
||||
Because of the second requirement, a Range object must be passed by
|
||||
|
||||
Because of the second requirement, a Range object must be passed by
|
||||
(const or non-const) reference in generic code.
|
||||
|
||||
</p>
|
||||
<p>
|
||||
The operations that can be performed on a Range is dependent on the
|
||||
<a href="../../iterator/doc/new-iter-concepts.html#iterator-traversal-concepts-lib-iterator-traversal">traversal
|
||||
The operations that can be performed on a Range is dependent on the
|
||||
<a href="../../iterator/doc/new-iter-concepts.html#iterator-traversal-concepts-lib-iterator-traversal">traversal
|
||||
category</a> of the underlying iterator type. Therefore
|
||||
the range concepts are named to reflect which traversal category its
|
||||
the range concepts are named to reflect which traversal category its
|
||||
iterators support. See also <a href="style.html">terminology and style guidelines.</a>
|
||||
for more information about naming of ranges.</p>
|
||||
|
||||
|
||||
<p> The concepts described below specifies associated types as
|
||||
<a href="../../mpl/doc/index.html#metafunctions">metafunctions</a> and all
|
||||
<a href="../../mpl/doc/refmanual/metafunction.html">metafunctions</a> and all
|
||||
functions as free-standing functions to allow for a layer of indirection. </p>
|
||||
|
||||
<p><i>Notice that these metafunctions must be defined in namespace </i>
|
||||
<code>boost</code></p>
|
||||
<!--<p><i>Notice that these metafunctions must be defined in namespace </i>
|
||||
<code>boost</code></p>-->
|
||||
|
||||
<hr>
|
||||
<a name="single_pass_range">
|
||||
@ -103,10 +103,10 @@ functions as free-standing functions to allow for a layer of indirection. </p>
|
||||
</TR>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
<h3>Description</h3>
|
||||
<p>
|
||||
A range X where <code>range_iterator<X>::type</code> is a model of <a
|
||||
A range X where <code>boost::range_iterator<X>::type</code> is a model of <a
|
||||
href="../../iterator/doc/new-iter-concepts.html#single-pass-iterators-lib-single-pass-iterators">
|
||||
Single Pass Iterator</a>
|
||||
|
||||
@ -118,20 +118,20 @@ Single Pass Iterator</a>
|
||||
<table border="1" cellpadding="5">
|
||||
<TR>
|
||||
<TD VAlign="top">Value type</TD>
|
||||
<TD VAlign="top"><code>range_value<X>::type</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_value<X>::type</code></TD>
|
||||
<TD VAlign="top">The type of the object stored in a Range.
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Iterator type</TD>
|
||||
<TD VAlign="top"><code>range_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">The type of iterator used to iterate through a Range's elements.
|
||||
The iterator's value type is expected to be the Range's value type. A
|
||||
<TD VAlign="top"><code>boost::range_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">The type of iterator used to iterate through a Range's elements.
|
||||
The iterator's value type is expected to be the Range's value type. A
|
||||
conversion from the iterator type to the const iterator type must exist.
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Const iterator type</TD>
|
||||
<TD VAlign="top"><code>range_const_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">A type of iterator that may be used to examine, but not to
|
||||
<TD VAlign="top"><code>boost::range_const_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">A type of iterator that may be used to examine, but not to
|
||||
modify, a Range's elements.</TD>
|
||||
</TR>
|
||||
<!--
|
||||
@ -157,20 +157,20 @@ Single Pass Iterator</a>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Beginning of range</TD>
|
||||
<TD VAlign="top"><code>begin(a)</code></TD>
|
||||
<TD VAlign="top"><code>range_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>range_const_iterator<X>::type</code>
|
||||
<TD VAlign="top"><code>boost::begin(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>boost::range_const_iterator<X>::type</code>
|
||||
otherwise</TD> </TR>
|
||||
<TR>
|
||||
<TD VAlign="top">End of range</TD>
|
||||
<TD VAlign="top"><code>end(a)</code></TD>
|
||||
<TD VAlign="top"><code>range_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>range_const_iterator<X>::type</code>
|
||||
<TD VAlign="top"><code>boost::end(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>boost::range_const_iterator<X>::type</code>
|
||||
otherwise</TD>
|
||||
</TR>
|
||||
<tr>
|
||||
<TD VAlign="top">Is range empty?</TD>
|
||||
<TD VAlign="top"><code>empty(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::empty(a)</code></TD>
|
||||
<TD VAlign="top">Convertible to <code>bool</code></TD>
|
||||
</TR>
|
||||
</table>
|
||||
@ -183,20 +183,20 @@ otherwise</TD>
|
||||
<TH>Postcondition</TH>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top"><code>begin(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::begin(a)</code></TD>
|
||||
<TD VAlign="top">Returns an iterator pointing to the first element in the Range.</TD>
|
||||
<TD VAlign="top"><code>begin(a)</code> is either dereferenceable or past-the-end.
|
||||
It is past-the-end if and only if <code>size(a) == 0</code>.</TD>
|
||||
<TD VAlign="top"><code>boost::begin(a)</code> is either dereferenceable or past-the-end.
|
||||
It is past-the-end if and only if <code>boost::size(a) == 0</code>.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top"><code>end(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::end(a)</code></TD>
|
||||
<TD VAlign="top">Returns an iterator pointing one past the last element in the
|
||||
Range.</TD>
|
||||
<TD VAlign="top"><code>end(a)</code> is past-the-end.</TD>
|
||||
<TD VAlign="top"><code>boost::end(a)</code> is past-the-end.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top"><code>empty(a)</code></TD>
|
||||
<TD VAlign="top">Equivalent to <code>begin(a) == end(a)</code>. (But possibly
|
||||
<TD VAlign="top"><code>boost::empty(a)</code></TD>
|
||||
<TD VAlign="top">Equivalent to <code>boost::begin(a) == boost::end(a)</code>. (But possibly
|
||||
faster.)</TD>
|
||||
<TD VAlign="top"> - </TD>
|
||||
</TR>
|
||||
@ -205,20 +205,20 @@ otherwise</TD>
|
||||
<h3>Complexity guarantees</h3>
|
||||
|
||||
All three functions are at most amortized linear time. For most practical
|
||||
purposes, one can expect <code>begin(a)</code>, <code>end(a)</code> and <code>empty(a)</code>
|
||||
purposes, one can expect <code>boost::begin(a)</code>, <code>boost::end(a)</code> and <code>boost::empty(a)</code>
|
||||
to be amortized constant time.
|
||||
|
||||
<h3>Invariants</h3>
|
||||
<Table border>
|
||||
<TR>
|
||||
<TD VAlign="top">Valid range</TD>
|
||||
<TD VAlign="top">For any Range <code>a</code>, <code>[begin(a),end(a))</code> is
|
||||
a valid range, that is, <code>end(a)</code> is reachable from <code>begin(a)</code>
|
||||
<TD VAlign="top">For any Range <code>a</code>, <code>[boost::begin(a),boost::end(a))</code> is
|
||||
a valid range, that is, <code>boost::end(a)</code> is reachable from <code>boost::begin(a)</code>
|
||||
in a finite number of increments.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Completeness</TD>
|
||||
<TD VAlign="top">An algorithm that iterates through the range <code>[begin(a),end(a))</code>
|
||||
<TD VAlign="top">An algorithm that iterates through the range <code>[boost::begin(a),boost::end(a))</code>
|
||||
will pass through every element of <code>a</code>.</TD>
|
||||
</tr>
|
||||
</table>
|
||||
@ -228,7 +228,7 @@ otherwise</TD>
|
||||
<p>
|
||||
<A href="http://www.sgi.com/Technology/STL/Container.html">Container</A>
|
||||
</p>
|
||||
<p> <a href="boost_range.html#range_value">implementation of
|
||||
<p> <a href="boost_range.html#boost::range_value">implementation of
|
||||
metafunctions </a></p>
|
||||
|
||||
<p> <a href="boost_range.html#begin">implementation of
|
||||
@ -251,7 +251,7 @@ otherwise</TD>
|
||||
|
||||
<h3>Description</h3>
|
||||
<p>
|
||||
A range <code>X</code> where <code>range_iterator<X>::type</code> is a model
|
||||
A range <code>X</code> where <code>boost::range_iterator<X>::type</code> is a model
|
||||
of <a
|
||||
href="../../iterator/doc/new-iter-concepts.html#forward-traversal-iterators-lib-forward-traversal-iterators">Forward Traversal Iterator</a>
|
||||
</p>
|
||||
@ -264,14 +264,14 @@ Range</a>
|
||||
<table cellpadding="5" border="1">
|
||||
<TR>
|
||||
<TD VAlign="top">Distance type</TD>
|
||||
<TD VAlign="top"><code>range_difference<X>::type</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_difference<X>::type</code></TD>
|
||||
<TD VAlign="top">A signed integral type used to represent the distance between
|
||||
two of the Range's iterators. This type must be the same as the iterator's
|
||||
distance type.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Size type</TD>
|
||||
<TD VAlign="top"><code>range_size<X>::type</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_size<X>::type</code></TD>
|
||||
<TD VAlign="top">An unsigned integral type that can represent any nonnegative
|
||||
value of the Range's distance type.</TD>
|
||||
</tr>
|
||||
@ -287,8 +287,8 @@ Range</a>
|
||||
</tr>
|
||||
<TR>
|
||||
<TD VAlign="top">Size of range</TD>
|
||||
<TD VAlign="top"><code>size(a)</code></TD>
|
||||
<TD VAlign="top"><code>range_size<X>::type</code></TD>
|
||||
<TD VAlign="top"><code>boost::size(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_size<X>::type</code></TD>
|
||||
</TR>
|
||||
</table>
|
||||
|
||||
@ -301,29 +301,29 @@ Range</a>
|
||||
<TH>Postcondition</TH>
|
||||
</TR>
|
||||
<tr>
|
||||
<TD VAlign="top"><code>size(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::size(a)</code></TD>
|
||||
<TD VAlign="top">Returns the size of the Range, that is, its number
|
||||
of elements. Note <code>size(a) == 0u</code> is equivalent to
|
||||
<code>empty(a).</code></TD>
|
||||
<TD VAlign="top"><code>size(a) >= 0</TD>
|
||||
of elements. Note <code>boost::size(a) == 0u</code> is equivalent to
|
||||
<code>boost::empty(a).</code></TD>
|
||||
<TD VAlign="top"><code>boost::size(a) >= 0</TD>
|
||||
</TR>
|
||||
</table>
|
||||
|
||||
<h3>Complexity guarantees</h3>
|
||||
|
||||
<p><code>size(a)</code> is at most amortized linear time.</p>
|
||||
<p><code>boost::size(a)</code> is at most amortized linear time.</p>
|
||||
|
||||
<h3>Invariants</h3>
|
||||
<p>
|
||||
<Table border="1" cellpadding="5">
|
||||
<TR>
|
||||
<TD VAlign="top">Range size</TD>
|
||||
<TD VAlign="top"><code>size(a)</code> is equal to the distance from <code>begin(a)</code>
|
||||
to <code>end(a)</code>.</TD> </table>
|
||||
<TD VAlign="top"><code>boost::size(a)</code> is equal to the distance from <code>boost::begin(a)</code>
|
||||
to <code>boost::end(a)</code>.</TD> </table>
|
||||
</p>
|
||||
|
||||
<h3>See also</h3>
|
||||
<p> <a href="boost_range.html#range_difference">implementation of
|
||||
<p> <a href="boost_range.html#boost::range_difference">implementation of
|
||||
metafunctions </a></p>
|
||||
|
||||
<p> <a href="boost_range.html#size">implementation of
|
||||
@ -347,7 +347,7 @@ of elements. Note <code>size(a) == 0u</code> is equivalent to
|
||||
|
||||
<h3>Description</h3> This concept provides access to iterators that traverse in
|
||||
both directions (forward and reverse). The
|
||||
<code>range_iterator<X>::type</code> iterator must meet all of the requirements
|
||||
<code>boost::range_iterator<X>::type</code> iterator must meet all of the requirements
|
||||
of <a
|
||||
href="../../iterator/doc/new-iter-concepts.html#bidirectional-traversal-iterator
|
||||
s-lib-bidirectional-traversal-iterators">Bidirectional Traversal Iterator.</a>
|
||||
@ -359,7 +359,7 @@ s-lib-bidirectional-traversal-iterators">Bidirectional Traversal Iterator.</a>
|
||||
<Table border>
|
||||
<TR>
|
||||
<TD VAlign="top">Reverse Iterator type</TD>
|
||||
<TD VAlign="top"><code>range_reverse_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_reverse_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">The type of iterator used to iterate through a Range's elements
|
||||
in reverse order. The iterator's value type is expected to be the Range's value
|
||||
type. A conversion from the reverse iterator type to the const reverse iterator
|
||||
@ -368,7 +368,7 @@ s-lib-bidirectional-traversal-iterators">Bidirectional Traversal Iterator.</a>
|
||||
<TR>
|
||||
<TD VAlign="top">Const reverse iterator type</TD>
|
||||
<TD
|
||||
VAlign="top"><code>range_const_reverse_iterator<X>::type</code></TD>
|
||||
VAlign="top"><code>boost::range_const_reverse_iterator<X>::type</code></TD>
|
||||
<TD VAlign="top">A type of reverse iterator that may be used to examine, but not
|
||||
to modify, a Range's elements.</TD>
|
||||
</TR>
|
||||
@ -386,27 +386,27 @@ VAlign="top"><code>range_const_reverse_iterator<X>::type</code></TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Beginning of range</TD>
|
||||
<TD VAlign="top"><code>rbegin(a)</code></TD>
|
||||
<TD VAlign="top"><code>range_reverse_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>range_const_reverse_iterator<X>::type</code>
|
||||
<TD VAlign="top"><code>rboost::begin(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_reverse_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>boost::range_const_reverse_iterator<X>::type</code>
|
||||
otherwise.</TD>
|
||||
<TD VAlign="top">Equivalent to
|
||||
<code>range_reverse_iterator<X>::type(end(a))</code>.</TD> </TR>
|
||||
<code>boost::range_reverse_iterator<X>::type(boost::end(a))</code>.</TD> </TR>
|
||||
<TR>
|
||||
<TD VAlign="top">End of range</TD>
|
||||
<TD VAlign="top"><code>rend(a)</code></TD>
|
||||
<TD VAlign="top"><code>range_reverse_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>range_const_reverse_iterator<X>::type</code>
|
||||
<TD VAlign="top"><code>rboost::end(a)</code></TD>
|
||||
<TD VAlign="top"><code>boost::range_reverse_iterator<X>::type</code> if
|
||||
<code>a</code> is mutable, <code>boost::range_const_reverse_iterator<X>::type</code>
|
||||
otherwise.</TD>
|
||||
<TD VAlign="top">Equivalent to
|
||||
<code>range_reverse_iterator<X>::type(begin(a))</code>.</TD> </tr>
|
||||
<code>boost::range_reverse_iterator<X>::type(boost::begin(a))</code>.</TD> </tr>
|
||||
|
||||
</table>
|
||||
|
||||
<h3>Complexity guarantees</h3>
|
||||
|
||||
<code>rbegin(a)</code> has the same complexity as <code>end(a)</code> and <code>rend(a)</code>
|
||||
has the same complexity as <code>begin(a)</code> from <a
|
||||
<code>rboost::begin(a)</code> has the same complexity as <code>boost::end(a)</code> and <code>rboost::end(a)</code>
|
||||
has the same complexity as <code>boost::begin(a)</code> from <a
|
||||
href="#forward_range">Forward Range</a>.
|
||||
|
||||
<h3>Invariants</h3>
|
||||
@ -414,20 +414,20 @@ otherwise.</TD>
|
||||
<Table border="1" cellpadding="5">
|
||||
<TR>
|
||||
<TD VAlign="top">Valid reverse range</TD>
|
||||
<TD VAlign="top">For any Bidirectional Range <code>a</code>, <code>[rbegin(a),rend(a))</code>
|
||||
is a valid range, that is, <code>rend(a)</code> is reachable from <code>rbegin(a)</code>
|
||||
<TD VAlign="top">For any Bidirectional Range <code>a</code>, <code>[rboost::begin(a),rboost::end(a))</code>
|
||||
is a valid range, that is, <code>rboost::end(a)</code> is reachable from <code>rboost::begin(a)</code>
|
||||
in a finite number of increments.</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD VAlign="top">Completeness</TD>
|
||||
<TD VAlign="top">An algorithm that iterates through the range <code>[rbegin(a),rend(a))</code>
|
||||
<TD VAlign="top">An algorithm that iterates through the range <code>[rboost::begin(a),rboost::end(a))</code>
|
||||
will pass through every element of <code>a</code>.</TD>
|
||||
</tr>
|
||||
</table>
|
||||
</p>
|
||||
|
||||
<h3>See also</h3>
|
||||
<p> <a href="boost_range.html#range_reverse_iterator">implementation of metafunctions </a></p>
|
||||
<p> <a href="boost_range.html#boost::range_reverse_iterator">implementation of metafunctions </a></p>
|
||||
|
||||
<p> <a href="boost_range.html#rbegin">implementation of
|
||||
functions </a></p>
|
||||
@ -436,7 +436,7 @@ otherwise.</TD>
|
||||
|
||||
<a name=random_access_range><h2>Random Access Range</h2> <h3>Description</h3>
|
||||
<p>
|
||||
A range <code>X</code> where <code>range_iterator<X>::type</code> is a model
|
||||
A range <code>X</code> where <code>boost::range_iterator<X>::type</code> is a model
|
||||
of <a
|
||||
|
||||
href="../../iterator/doc/new-iter-concepts.html#random-access-traversal-iterators
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
<h2>Terminology and style guidelines </h2>
|
||||
|
||||
<p>
|
||||
The use of a consistent terminology is as important for <a href="range.html#range">Range</a>s
|
||||
The use of a consistent terminology is as important for <a href="range.html">Range</a>s
|
||||
and range-based algorithms as it is for iterators and iterator-based algorithms.
|
||||
If a conventional set of names are adopted, we can avoid misunderstandings and
|
||||
write generic function prototypes that are <i>self-documenting</i>.
|
||||
|
||||
@ -39,11 +39,11 @@
|
||||
<li><a href="doc/range.html">Range concepts:</a>
|
||||
<ul>
|
||||
<li> <a href="doc/range.html#single_pass_range">SinglePassRange</a>
|
||||
<li> <a href="doc/range.html#range">ForwardRange</a>
|
||||
<li> <a href="doc/range.html#forward_range">ForwardRange</a>
|
||||
<li> <a href="doc/range.html#bidirectional_range">BidirectionalRange</a>
|
||||
<li> <a href="doc/range.html#random_access_range">RandomAccessRange</a> </ul>
|
||||
|
||||
<li> <a href="doc/boost_range.html">Synopsis and Reference</a>
|
||||
<li> <a href="doc/boost_range.html">Reference</a>
|
||||
<li> <a href="doc/utility_class.html"> Utilities:</a>
|
||||
<ul>
|
||||
<li> Class <a href="doc/utility_class.html#iter_range"><code>iterator_range</code></a>
|
||||
|
||||
Reference in New Issue
Block a user