tmp/tmpfzi57vvh/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,175 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
### Common algorithm requirements <a id="alg.req">[[alg.req]]</a>
|
| 2 |
+
|
| 3 |
+
#### General <a id="alg.req.general">[[alg.req.general]]</a>
|
| 4 |
+
|
| 5 |
+
There are several additional iterator concepts that are commonly applied
|
| 6 |
+
to families of algorithms. These group together iterator requirements of
|
| 7 |
+
algorithm families. There are three relational concepts that specify how
|
| 8 |
+
element values are transferred between `indirectly_readable` and
|
| 9 |
+
`indirectly_writable` types: `indirectly_movable`,
|
| 10 |
+
`indirectly_copyable`, and `indirectly_swappable`. There are three
|
| 11 |
+
relational concepts for rearrangements: `permutable`, `mergeable`, and
|
| 12 |
+
`sortable`. There is one relational concept for comparing values from
|
| 13 |
+
different sequences: `indirectly_comparable`.
|
| 14 |
+
|
| 15 |
+
[*Note 1*: The `ranges::less` function object type used in the concepts
|
| 16 |
+
below imposes constraints on the concepts’ arguments in addition to
|
| 17 |
+
those that appear in the concepts’ bodies [[range.cmp]]. — *end note*]
|
| 18 |
+
|
| 19 |
+
#### Concept <a id="alg.req.ind.move">[[alg.req.ind.move]]</a>
|
| 20 |
+
|
| 21 |
+
The `indirectly_movable` concept specifies the relationship between a
|
| 22 |
+
`indirectly_readable` type and a `indirectly_writable` type between
|
| 23 |
+
which values may be moved.
|
| 24 |
+
|
| 25 |
+
``` cpp
|
| 26 |
+
template<class In, class Out>
|
| 27 |
+
concept indirectly_movable =
|
| 28 |
+
indirectly_readable<In> &&
|
| 29 |
+
indirectly_writable<Out, iter_rvalue_reference_t<In>>;
|
| 30 |
+
```
|
| 31 |
+
|
| 32 |
+
The `indirectly_movable_storable` concept augments `indirectly_movable`
|
| 33 |
+
with additional requirements enabling the transfer to be performed
|
| 34 |
+
through an intermediate object of the `indirectly_readable` type’s value
|
| 35 |
+
type.
|
| 36 |
+
|
| 37 |
+
``` cpp
|
| 38 |
+
template<class In, class Out>
|
| 39 |
+
concept indirectly_movable_storable =
|
| 40 |
+
indirectly_movable<In, Out> &&
|
| 41 |
+
indirectly_writable<Out, iter_value_t<In>> &&
|
| 42 |
+
movable<iter_value_t<In>> &&
|
| 43 |
+
constructible_from<iter_value_t<In>, iter_rvalue_reference_t<In>> &&
|
| 44 |
+
assignable_from<iter_value_t<In>&, iter_rvalue_reference_t<In>>;
|
| 45 |
+
```
|
| 46 |
+
|
| 47 |
+
Let `i` be a dereferenceable value of type `In`. `In` and `Out` model
|
| 48 |
+
`indirectly_movable_storable<In, Out>` only if after the initialization
|
| 49 |
+
of the object `obj` in
|
| 50 |
+
|
| 51 |
+
``` cpp
|
| 52 |
+
iter_value_t<In> obj(ranges::iter_move(i));
|
| 53 |
+
```
|
| 54 |
+
|
| 55 |
+
`obj` is equal to the value previously denoted by `*i`. If
|
| 56 |
+
`iter_rvalue_reference_t<In>` is an rvalue reference type, the resulting
|
| 57 |
+
state of the value denoted by `*i` is valid but unspecified
|
| 58 |
+
[[lib.types.movedfrom]].
|
| 59 |
+
|
| 60 |
+
#### Concept <a id="alg.req.ind.copy">[[alg.req.ind.copy]]</a>
|
| 61 |
+
|
| 62 |
+
The `indirectly_copyable` concept specifies the relationship between a
|
| 63 |
+
`indirectly_readable` type and a `indirectly_writable` type between
|
| 64 |
+
which values may be copied.
|
| 65 |
+
|
| 66 |
+
``` cpp
|
| 67 |
+
template<class In, class Out>
|
| 68 |
+
concept indirectly_copyable =
|
| 69 |
+
indirectly_readable<In> &&
|
| 70 |
+
indirectly_writable<Out, iter_reference_t<In>>;
|
| 71 |
+
```
|
| 72 |
+
|
| 73 |
+
The `indirectly_copyable_storable` concept augments
|
| 74 |
+
`indirectly_copyable` with additional requirements enabling the transfer
|
| 75 |
+
to be performed through an intermediate object of the
|
| 76 |
+
`indirectly_readable` type’s value type. It also requires the capability
|
| 77 |
+
to make copies of values.
|
| 78 |
+
|
| 79 |
+
``` cpp
|
| 80 |
+
template<class In, class Out>
|
| 81 |
+
concept indirectly_copyable_storable =
|
| 82 |
+
indirectly_copyable<In, Out> &&
|
| 83 |
+
indirectly_writable<Out, iter_value_t<In>&> &&
|
| 84 |
+
indirectly_writable<Out, const iter_value_t<In>&> &&
|
| 85 |
+
indirectly_writable<Out, iter_value_t<In>&&> &&
|
| 86 |
+
indirectly_writable<Out, const iter_value_t<In>&&> &&
|
| 87 |
+
copyable<iter_value_t<In>> &&
|
| 88 |
+
constructible_from<iter_value_t<In>, iter_reference_t<In>> &&
|
| 89 |
+
assignable_from<iter_value_t<In>&, iter_reference_t<In>>;
|
| 90 |
+
```
|
| 91 |
+
|
| 92 |
+
Let `i` be a dereferenceable value of type `In`. `In` and `Out` model
|
| 93 |
+
`indirectly_copyable_storable<In, Out>` only if after the initialization
|
| 94 |
+
of the object `obj` in
|
| 95 |
+
|
| 96 |
+
``` cpp
|
| 97 |
+
iter_value_t<In> obj(*i);
|
| 98 |
+
```
|
| 99 |
+
|
| 100 |
+
`obj` is equal to the value previously denoted by `*i`. If
|
| 101 |
+
`iter_reference_t<In>` is an rvalue reference type, the resulting state
|
| 102 |
+
of the value denoted by `*i` is valid but unspecified
|
| 103 |
+
[[lib.types.movedfrom]].
|
| 104 |
+
|
| 105 |
+
#### Concept <a id="alg.req.ind.swap">[[alg.req.ind.swap]]</a>
|
| 106 |
+
|
| 107 |
+
The `indirectly_swappable` concept specifies a swappable relationship
|
| 108 |
+
between the values referenced by two `indirectly_readable` types.
|
| 109 |
+
|
| 110 |
+
``` cpp
|
| 111 |
+
template<class I1, class I2 = I1>
|
| 112 |
+
concept indirectly_swappable =
|
| 113 |
+
indirectly_readable<I1> && indirectly_readable<I2> &&
|
| 114 |
+
requires(const I1 i1, const I2 i2) {
|
| 115 |
+
ranges::iter_swap(i1, i1);
|
| 116 |
+
ranges::iter_swap(i2, i2);
|
| 117 |
+
ranges::iter_swap(i1, i2);
|
| 118 |
+
ranges::iter_swap(i2, i1);
|
| 119 |
+
};
|
| 120 |
+
```
|
| 121 |
+
|
| 122 |
+
#### Concept <a id="alg.req.ind.cmp">[[alg.req.ind.cmp]]</a>
|
| 123 |
+
|
| 124 |
+
The `indirectly_comparable` concept specifies the common requirements of
|
| 125 |
+
algorithms that compare values from two different sequences.
|
| 126 |
+
|
| 127 |
+
``` cpp
|
| 128 |
+
template<class I1, class I2, class R, class P1 = identity,
|
| 129 |
+
class P2 = identity>
|
| 130 |
+
concept indirectly_comparable =
|
| 131 |
+
indirect_binary_predicate<R, projected<I1, P1>, projected<I2, P2>>;
|
| 132 |
+
```
|
| 133 |
+
|
| 134 |
+
#### Concept <a id="alg.req.permutable">[[alg.req.permutable]]</a>
|
| 135 |
+
|
| 136 |
+
The `permutable` concept specifies the common requirements of algorithms
|
| 137 |
+
that reorder elements in place by moving or swapping them.
|
| 138 |
+
|
| 139 |
+
``` cpp
|
| 140 |
+
template<class I>
|
| 141 |
+
concept permutable =
|
| 142 |
+
forward_iterator<I> &&
|
| 143 |
+
indirectly_movable_storable<I, I> &&
|
| 144 |
+
indirectly_swappable<I, I>;
|
| 145 |
+
```
|
| 146 |
+
|
| 147 |
+
#### Concept <a id="alg.req.mergeable">[[alg.req.mergeable]]</a>
|
| 148 |
+
|
| 149 |
+
The `mergeable` concept specifies the requirements of algorithms that
|
| 150 |
+
merge sorted sequences into an output sequence by copying elements.
|
| 151 |
+
|
| 152 |
+
``` cpp
|
| 153 |
+
template<class I1, class I2, class Out, class R = ranges::less,
|
| 154 |
+
class P1 = identity, class P2 = identity>
|
| 155 |
+
concept mergeable =
|
| 156 |
+
input_iterator<I1> &&
|
| 157 |
+
input_iterator<I2> &&
|
| 158 |
+
weakly_incrementable<Out> &&
|
| 159 |
+
indirectly_copyable<I1, Out> &&
|
| 160 |
+
indirectly_copyable<I2, Out> &&
|
| 161 |
+
indirect_strict_weak_order<R, projected<I1, P1>, projected<I2, P2>>;
|
| 162 |
+
```
|
| 163 |
+
|
| 164 |
+
#### Concept <a id="alg.req.sortable">[[alg.req.sortable]]</a>
|
| 165 |
+
|
| 166 |
+
The `sortable` concept specifies the common requirements of algorithms
|
| 167 |
+
that permute sequences into ordered sequences (e.g., `sort`).
|
| 168 |
+
|
| 169 |
+
``` cpp
|
| 170 |
+
template<class I, class R = ranges::less, class P = identity>
|
| 171 |
+
concept sortable =
|
| 172 |
+
permutable<I> &&
|
| 173 |
+
indirect_strict_weak_order<R, projected<I, P>>;
|
| 174 |
+
```
|
| 175 |
+
|