Merged from 1.33.0 release

[SVN r30540]

doc/boost_range.html

@@ -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 
+    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 
+    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>&amp; </span><span class=identifier
             <td  ><code  >range_difference&lt;X&gt;::type</code></td>
             <td  ><code  >T::difference_type</code><br>
                 <code
->boost_iterator_difference&lt;P::first_type&gt;::type</code><br>
+>boost::iterator_difference&lt;P::first_type&gt;::type</code><br>
                 <code  >std::ptrdiff_t</code><br>
                 <code  >std::ptrdiff_t</code><br>
             <td  >compile time</td>

doc/examples.html

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

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&lt;C&gt;::type</code> 
+            <i>Why is there no difference between <code  >range_iterator&lt;C&gt;::type</code>
             and <code  >range_const_iterator&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>. 
+        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&lt;const_iterator,const_iterator&gt;</code> 
+        When it is possible to come up with one, the client might choose to construct a <code  >std::pair&lt;const_iterator,const_iterator&gt;</code>
         object.
         </p>
         <p>
-        Note that an <a href="utility_class.html#iter_range">iterator_range</a> 
+        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 
+        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 
+        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 
+            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 
+            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 
+            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 
+            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 
+            much sense for ranges; for example, we cannot determine the size and
-            emptiness of a range since we cannot even compare 
+            emptiness of a range since we cannot even compare
-            its iterators. 
+            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 
+            The answer to the first question is that "it's up to you". The
-            answer to the second question is Yes. Normally qualified syntax 
+            answer to the second question is Yes. Normally qualified syntax
-            disables ADL, but the functions are implemented in a special 
+            disables ADL, but the functions are implemented in a special
-            manner that preserves ADL properties. The trick was explained by 
+            manner that preserves ADL properties. The trick was explained by
-            Daniel Frey on comp.lang.std.c++ in the thread "Whence Swap" and 
+            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>&lt; </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>&gt;            
+        </span><span class=keyword>template</span><span class=special>&lt; </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>&gt;
         </span><span class=keyword>typename </span><span class=identifier>range_iterator</span><span class=special>&lt;</span><span class=identifier>T</span><span class=special>&gt;:</span><span class=identifier>type </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>T</span><span class=special>&amp; </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=special>}
-                
+
-    </span><span class=keyword>template</span><span class=special>&lt; </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>&gt;                
+    </span><span class=keyword>template</span><span class=special>&lt; </span><span class=keyword>class </span><span class=identifier>T </span><span class=special>&gt;
     </span><span class=keyword>typename </span><span class=identifier>range_iterator</span><span class=special>&lt;</span><span class=identifier>T</span><span class=special>&gt;::</span><span class=identifier>type </span><span class=identifier>begin</span><span class=special>( </span><span class=identifier>T</span><span class=special>&amp; </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>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>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>            
+</blockquote>
-Cool indeed!            
+Cool indeed!
 </p>
-     -->       
+     -->
 
     </ol>
 

doc/intro.html

@@ -18,36 +18,36 @@
 
     <h2>Introduction</h2>
     <p>
-    Generic algorithms have so far been specified in terms of two or more 
+    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 
+    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 
+    enough functionality to satisfy the needs of the generic code
-    <i>if a suitable layer of indirection is applied </i>.  For 
+    <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 
+    works with containers, provided a suitable adapter is used. Likewise, null
-    terminated strings can be treated as containers of characters, if suitably 
+    terminated strings can be treated as containers of characters, if suitably
-    adapted. 
+    adapted.
-    </p> 
+    </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 
+    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. 
+    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 
+The basic idea is to add another layer of indirection using <a
-href="../../mpl/doc/index.html#metafunctions">metafunctions</a> and 
+href="../../mpl/doc/refmanual/metafunction.html">metafunctions</a> and
-free-standing functions so syntactic and/or semantic differences can be removed. 
+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 

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 
+               information about the number of elements in the Range.  However, a Range has
-               fewer requirements than a Container. 
+               fewer requirements than a Container.
-              </p> 
+              </p>
               <p>
-               The motivation for the Range concept is 
+               The motivation for the Range concept is
-               that there are many useful Container-like types that do not meet the full 
+               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 
+               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 
+    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 
+    <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>
+<!--<p><i>Notice that these metafunctions must be defined in namespace </i>
-<code>boost</code></p>
+<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&lt;X>::type</code> is a model of <a 
+    A range X where <code>boost::range_iterator&lt;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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_value&lt;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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_iterator&lt;X>::type</code></TD>
-            <TD VAlign="top">The type of iterator used to iterate through a Range's elements. 
+            <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 
+            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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_const_iterator&lt;X>::type</code></TD>
-            <TD VAlign="top">A type of iterator that may be used to examine, but not to 
+            <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>boost::begin(a)</code></TD>
-            <TD VAlign="top"><code>range_iterator&lt;X>::type</code> if 
+            <TD VAlign="top"><code>boost::range_iterator&lt;X>::type</code> if
-<code>a</code> is mutable, <code>range_const_iterator&lt;X>::type</code> 
+<code>a</code> is mutable, <code>boost::range_const_iterator&lt;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>boost::end(a)</code></TD>
-            <TD VAlign="top"><code>range_iterator&lt;X>::type</code> if 
+            <TD VAlign="top"><code>boost::range_iterator&lt;X>::type</code> if
-<code>a</code> is mutable, <code>range_const_iterator&lt;X>::type</code> 
+<code>a</code> is mutable, <code>boost::range_const_iterator&lt;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. 
+            <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>size(a) == 0</code>.</TD>
+            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"><code>boost::empty(a)</code></TD>
-            <TD VAlign="top">Equivalent to <code>begin(a) == end(a)</code>. (But possibly 
+            <TD VAlign="top">Equivalent to <code>boost::begin(a) == boost::end(a)</code>. (But possibly 
             faster.)</TD>
             <TD VAlign="top">&nbsp;-&nbsp;</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 
+            <TD VAlign="top">For any Range <code>a</code>, <code>[boost::begin(a),boost::end(a))</code> is 
-            a valid range, that is, <code>end(a)</code> is reachable from <code>begin(a)</code> 
+            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&lt;X>::type</code> is a model 
+    A range <code>X</code> where <code>boost::range_iterator&lt;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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_difference&lt;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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_size&lt;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>boost::size(a)</code></TD>
-            <TD VAlign="top"><code>range_size&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_size&lt;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 
+of elements. Note <code>boost::size(a) == 0u</code> is equivalent to 
-<code>empty(a).</code></TD>
+<code>boost::empty(a).</code></TD>
-            <TD VAlign="top"><code>size(a) &gt;= 0</TD>
+            <TD VAlign="top"><code>boost::size(a) &gt;= 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> 
+            <TD VAlign="top"><code>boost::size(a)</code> is equal to the distance from <code>boost::begin(a)</code>
-            to <code>end(a)</code>.</TD> </table>
+            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&lt;X>::type</code> iterator must meet all of the requirements 
+<code>boost::range_iterator&lt;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&lt;X>::type</code></TD>
+            <TD VAlign="top"><code>boost::range_reverse_iterator&lt;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&ltX>::type</code></TD>
+VAlign="top"><code>boost::range_const_reverse_iterator&ltX>::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&ltX>::type</code></TD>
         </TR>
         <TR>
             <TD VAlign="top">Beginning of range</TD>
-            <TD VAlign="top"><code>rbegin(a)</code></TD>
+            <TD VAlign="top"><code>rboost::begin(a)</code></TD>
-            <TD VAlign="top"><code>range_reverse_iterator&lt;X>::type</code> if 
+            <TD VAlign="top"><code>boost::range_reverse_iterator&lt;X>::type</code> if
-<code>a</code> is mutable, <code>range_const_reverse_iterator&lt;X>::type</code> 
+<code>a</code> is mutable, <code>boost::range_const_reverse_iterator&lt;X>::type</code>
 otherwise.</TD>
             <TD VAlign="top">Equivalent to 
-<code>range_reverse_iterator&lt;X>::type(end(a))</code>.</TD> </TR>
+<code>boost::range_reverse_iterator&lt;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>rboost::end(a)</code></TD>
-            <TD VAlign="top"><code>range_reverse_iterator&lt;X>::type</code> if 
+            <TD VAlign="top"><code>boost::range_reverse_iterator&lt;X>::type</code> if
-<code>a</code> is mutable, <code>range_const_reverse_iterator&lt;X>::type</code> 
+<code>a</code> is mutable, <code>boost::range_const_reverse_iterator&lt;X>::type</code>
 otherwise.</TD>
             <TD VAlign="top">Equivalent to 
-<code>range_reverse_iterator&lt;X>::type(begin(a))</code>.</TD> </tr>
+<code>boost::range_reverse_iterator&lt;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> 
+    <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>begin(a)</code> from <a
+    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> 
+            <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>rend(a)</code> is reachable from <code>rbegin(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&lt;X>::type</code> is a model 
+    A range <code>X</code> where <code>boost::range_iterator&lt;X>::type</code> is a model
 of <a
       
 href="../../iterator/doc/new-iter-concepts.html#random-access-traversal-iterators

doc/style.html

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

index.html

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