1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Boost.Range FAQ </title>
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body>
<table border="0" >
<tr>
<td ><img src="../../../boost.png" border="0" ></td>
<td ><h1 align="center">Boost.Range</h1></td>
</tr>
</table>
<p>
<h2 >FAQ</h2> <a name="FAQ" ></a>
<ol >
<li >
<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>
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
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
serve most
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
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>
<p>
Note also that incrementable iterators are derived from output
iterators and so there exist no output range.
</p>
</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
<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
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>
<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=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=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>//
// 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=special>}</span>
<span class=special>} </span>
</pre>
</blockquote>
Cool indeed!
</p>
-->
</ol>
<hr>
<p>
(C) Copyright Thorsten Ottosen 2003-2004
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
|
