feedc0de/boost_range
1
0
Fork 0
forked from boostorg/range
Code Pull Requests Activity

*** empty log message ***

Browse Source 
[SVN r24368]
This commit is contained in:
Thorsten Jørgen Ottosen
2004-08-10 09:56:55 +00:00
parent 7b37911918
commit 6157440017
11 changed files with 989 additions and 626 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/faq.html
+62 -15
View File
@@ -17,12 +17,12 @@
</table>
<p>
<h2 >FAQ</h2>
<a name="FAQ" ></a>
<h2 >FAQ</h2> <a name="FAQ" ></a>
<ol >
<li >
Why is there no difference between <code >iterator_of&lt;C&gt;::type</code> and <code >const_iterator_of&lt;C&gt;::type</code>
for <code >std::pair&lt;iterator, iterator&gt;</code>.
<i>Why is there no difference between <code >iterator_of&lt;C&gt;::type</code>
and <code >const_iterator_of&lt;C&gt;::type</code> for <code >std::pair&lt;iterator,
iterator&gt;</code></i>.
</li>
<p >
In general it is not possible nor desirable to find a corresponding <code >const_iterator</code>.
@@ -30,24 +30,71 @@
object.
</p>
<li >
Why is there not supplied more types or more functions?
<i>Why is there not supplied more types or more functions?</i>
<p >
The library have been kept small because its current interface will serve
most purposes. If and when a genuine need arises for more functionality, it can
be implemented.
The library have been kept small because its current interface will serve most
purposes. If and when a genuine need arises for more functionality, it can be
implemented.
</p>
</li>
<li >
How should I implement generic algorithms for ranges?
<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 the public interface.
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>
<li>
<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.
</p>
</li>
<li>
<i>Should I use qualified syntax, for example
<blockquote><pre>boost::begin( r ); </pre></blockquote>
instead of
<blockquote>
<pre>using namespace boost;
begin( r )</pre></blockquote>
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
it is best explained by some code: <blockquote>
<pre>
namespace boost
{
namespace range_detail
{
template< class T >
typename iterator_of&lt;T>:type begin( T& r )
{ /* normal implementation */ }
}
template< class T >
typename iterator_of&lt;T>::type begin( T& r )
{
//
// Create ADL hook
//
using range_detail::begin;
return begin( r );
}
} </pre>
</blockquote>
</p>
</ol>