From e82a7fab5da10bc817584cb3d4ae68596677c78e Mon Sep 17 00:00:00 2001 From: Douglas Gregor Date: Fri, 12 Aug 2005 13:02:37 +0000 Subject: [PATCH] Merged from 1.33.0 release [SVN r30540] --- doc/boost_range.html | 11 +++- doc/examples.html | 7 +- doc/faq.html | 76 +++++++++++----------- doc/intro.html | 48 +++++++------- doc/range.html | 148 +++++++++++++++++++++---------------------- doc/style.html | 2 +- index.html | 4 +- 7 files changed, 155 insertions(+), 141 deletions(-) diff --git a/doc/boost_range.html b/doc/boost_range.html index dbc6342..79b54c1 100644 --- a/doc/boost_range.html +++ b/doc/boost_range.html @@ -46,14 +46,19 @@
  • null terminated strings (this includes char[],wchar_t[], char*, and wchar_t*) +

    + Warning: support for null-terminated strings is deprecated and will + disappear in the next Boost release (1.34). +

    +
  • built-in arrays
    • - 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 iterator_range implements the minimal interface required to make the @@ -287,7 +292,7 @@ class=identifier>T& range_difference<X>::type T::difference_type
    boost_iterator_difference<P::first_type>::type
    +>boost::iterator_difference<P::first_type>::type
    std::ptrdiff_t
    std::ptrdiff_t
    compile time diff --git a/doc/examples.html b/doc/examples.html index 8d34285..6db7253 100755 --- a/doc/examples.html +++ b/doc/examples.html @@ -24,8 +24,13 @@
  • string.cpp
    • - shows how to implement a container version of std::find() that + shows how to implement a container version of std::find() that works with char[],wchar_t[],char*,wchar_t*. +

    + Warning: support for null-terminated strings is deprecated and will + disappear in the next Boost release (1.34). +

    +
  • algorithm_example.cpp diff --git a/doc/faq.html b/doc/faq.html index 7ae9f6a..34304ef 100755 --- a/doc/faq.html +++ b/doc/faq.html @@ -20,36 +20,36 @@

    FAQ

    1. - Why is there no difference between range_iterator<C>::type + Why is there no difference between range_iterator<C>::type and range_const_iterator<C>::type for std::pair<iterator, iterator>.

      2. - In general it is not possible nor desirable to find a corresponding const_iterator. - When it is possible to come up with one, the client might choose to construct a std::pair<const_iterator,const_iterator> + In general it is not possible nor desirable to find a corresponding const_iterator. + When it is possible to come up with one, the client might choose to construct a std::pair<const_iterator,const_iterator> object.

      - Note that an iterator_range - is somewhat more convenient than a pair and that a sub_range do + Note that an iterator_range + is somewhat more convenient than a pair and that a sub_range does propagate const-ness.

      - +
    2. Why is there not supplied more types or more functions?

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

    3. How should I implement generic algorithms for ranges?

      - 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 not 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 not to expose the iterator version in the public interface.

      4. @@ -57,59 +57,59 @@ Why is there no Incrementable Range concept?

      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.

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

      - + + -->
    diff --git a/doc/intro.html b/doc/intro.html index 9fec4f8..0161f42 100755 --- a/doc/intro.html +++ b/doc/intro.html @@ -18,36 +18,36 @@

    Introduction

    - 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 Ranges as much as possible.

    - +

    - 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 - if a suitable layer of indirection is applied . For + enough functionality to satisfy the needs of the generic code + if a suitable layer of indirection is applied . 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. -

    - + works with containers, provided a suitable adapter is used. Likewise, null + terminated strings can be treated as containers of characters, if suitably + adapted. +

    +

    - This library therefore provides the means to adapt standard-like + This library therefore provides the means to adapt standard-like containers, - null terminated strings, std::pairs 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 metafunctions and -free-standing functions so syntactic and/or semantic differences can be removed. + null terminated strings, std::pairs 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 metafunctions and +free-standing functions so syntactic and/or semantic differences can be removed.

    @@ -61,15 +61,19 @@ free-standing functions so syntactic and/or semantic differences can be removed.

  • correct handling of null-terminated strings +

    + Warning: support for null-terminated strings is deprecated and will + disappear in the next Boost release (1.34). +

  • - 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?)

    • - Below are given a small example (the complete example can be found here + Below are given a small example (the complete example can be found here ): 

    @@ -130,7 +134,7 @@ class=identifier>assign( 
 
     By using the free-standing functions and metafunctions, the code automatically 
+href="../../mpl/doc/refmanual/metafunction.html">metafunctions, 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 find() since we cannot forward a non-const 
diff --git a/doc/range.html b/doc/range.html
index 704b68a..b2f907c 100755
--- a/doc/range.html
+++ b/doc/range.html
@@ -44,16 +44,16 @@
 
     
    
     A Range is a concept similar to the STL Container concept. A 
+               href="http://www.sgi.com/Technology/STL/Container.html">Container concept. A
                Range provides iterators for accessing a half-open range
 [first,one_past_last) of elements and provides
-               information about the number of elements in the Range.  However, a Range has 
-               fewer requirements than a Container. 
-              
     
+               information about the number of elements in the Range.  However, a Range has
+               fewer requirements than a Container.
+              
    
               
    
-               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
 
     
      
@@ -67,25 +67,25 @@
             -->
     
    
 
-    
-    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.
 
     
    
     
    
-    The operations that can be performed on a Range is dependent on the 
-    traversal 
+    The operations that can be performed on a Range is dependent on the
+    traversal
 category 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 terminology and style guidelines.
     for more information about naming of ranges.
    
-    
+
     
     The concepts described below specifies associated types as
-metafunctions and all 
+metafunctions and all
 functions as free-standing functions to allow for a layer of indirection. 
    
 
-
    Notice that these metafunctions must be defined in namespace 
-boost
    
+
 
     
    
     
@@ -103,10 +103,10 @@ functions as free-standing functions to allow for a layer of indirection. 
    
         
     
 
-    
+
     
    Description
    
     
    
-    A range X where range_iterator<X>::type is a model of boost::range_iterator<X>::type is a model of 
 Single Pass Iterator
 
@@ -118,20 +118,20 @@ Single Pass Iterator
     
-            
+            
-            
-            
+            
-            
-            
+            
    
         
    
             Value typerange_value<X>::typeboost::range_value<X>::type
             The type of the object stored in a Range.
         
    
         
    
             Iterator typerange_iterator<X>::typeThe 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 
+            boost::range_iterator<X>::typeThe 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.
         
    
         
    
             Const iterator typerange_const_iterator<X>::typeA type of iterator that may be used to examine, but not to 
+            boost::range_const_iterator<X>::typeA type of iterator that may be used to examine, but not to
             modify, a Range's elements.