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/intro.html b/doc/intro.html index fe19883..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 ):

    diff --git a/doc/range.html b/doc/range.html
    index 71c9720..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.