Imported Upstream version 1.57.0

[platform/upstream/boost.git] / libs / range / doc / reference / adaptors.qbk

diff --git a/libs/range/doc/reference/adaptors.qbk b/libs/range/doc/reference/adaptors.qbk
index 91401c0..b3efaee 100644 (file)
--- a/libs/range/doc/reference/adaptors.qbk
+++ b/libs/range/doc/reference/adaptors.qbk
@@ -69,7 +69,7 @@ What should we do if we only want to copy an element `a` if it satisfies some pr
 * `boost::copy_if( rng, pred, out )`
 * `boost::count_if( rng, pred )`
 
-These algorithms are only defined to maintain a one to one relationship with the standard library algorithms. This approach of adding algorithm suffers a combinatorial explosion. Inevitably many algorithms are missing `_if` variants and there is redundant development overhead for each new algorithm. The Adaptor Generator is the design solution to this problem.
+These algorithms are only defined to maintain a one to one relationship with the standard library algorithms. This approach of adding algorithm suffers a combinatorial explosion. Inevitably many algorithms are missing `_if` variants and there is redundant development overhead for each new algorithm. The Adaptor Generator is the design solution to this problem. It is conceivable that some algorithms are capable of optimization by tightly coupling the filter with the algorithm. The adaptors provide a more general solution with superior separation of orthogonal concerns.
 
 [heading Range Adaptor alternative to copy_if algorithm]
 ``
@@ -86,14 +86,14 @@ boost::count_if( rng, pred );
 ``
 can be expressed as
 ``
-boost::count( rng | boost::adaptors::filtered(pred), out );
+boost::size( rng | boost::adaptors::filtered(pred) );
 ``
 
-What this means is that ['*no*] algorithm with the `_if` suffix is needed. Furthermore, it turns out that algorithms with the `_copy` suffix are not needed either. Consider the somewhat misdesigned `replace_copy_if()` which may be used as
+What this means is that many algorithms no longer require nor benefit from an optimized implementation with an `_if` suffix. Furthermore, it turns out that algorithms with the `_copy` suffix are often not needed either. Consider `replace_copy_if()` which may be used as
 
 ``
 std::vector<int> vec;
-boost::replace_copy_if( rng, std::back_inserter(vec), pred );
+boost::replace_copy_if( rng, std::back_inserter(vec), pred, new_value );
 ``
 
 With adaptors and algorithms we can express this as
@@ -116,7 +116,7 @@ boost::push_back(vec, rng | boost::adaptors::replaced_if(pred, new_value)
 
 In this manner, the ['*composition*] of Range Adaptors has the following consequences:
 
-1. we no longer need `_if`, `_copy`, `_copy_if` and `_n` variants of algorithms.
+1. we no longer need many of the `_if`, `_copy`, `_copy_if` and `_n` variants of algorithms.
 
 2. we can generate a multitude of new algorithms on the fly, for example, above we generated `reverse_replace_copy_if()`