tmp/tmpzpei5g9d/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,118 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
#### Concept <a id="iterator.concept.winc">[[iterator.concept.winc]]</a>
|
| 2 |
+
|
| 3 |
+
The `weakly_incrementable` concept specifies the requirements on types
|
| 4 |
+
that can be incremented with the pre- and post-increment operators. The
|
| 5 |
+
increment operations are not required to be equality-preserving, nor is
|
| 6 |
+
the type required to be `equality_comparable`.
|
| 7 |
+
|
| 8 |
+
``` cpp
|
| 9 |
+
template<class T>
|
| 10 |
+
inline constexpr bool is-integer-like = see below; // exposition only
|
| 11 |
+
|
| 12 |
+
template<class T>
|
| 13 |
+
inline constexpr bool is-signed-integer-like = see below; // exposition only
|
| 14 |
+
|
| 15 |
+
template<class I>
|
| 16 |
+
concept weakly_incrementable =
|
| 17 |
+
default_initializable<I> && movable<I> &&
|
| 18 |
+
requires(I i) {
|
| 19 |
+
typename iter_difference_t<I>;
|
| 20 |
+
requires is-signed-integer-like<iter_difference_t<I>>;
|
| 21 |
+
{ ++i } -> same_as<I&>; // not required to be equality-preserving
|
| 22 |
+
i++; // not required to be equality-preserving
|
| 23 |
+
};
|
| 24 |
+
```
|
| 25 |
+
|
| 26 |
+
A type `I` is an *integer-class type* if it is in a set of
|
| 27 |
+
implementation-defined class types that behave as integer types do, as
|
| 28 |
+
defined in below.
|
| 29 |
+
|
| 30 |
+
The range of representable values of an integer-class type is the
|
| 31 |
+
continuous set of values over which it is defined. The values 0 and 1
|
| 32 |
+
are part of the range of every integer-class type. If any negative
|
| 33 |
+
numbers are part of the range, the type is a
|
| 34 |
+
*signed-integer-class type*; otherwise, it is an
|
| 35 |
+
*unsigned-integer-class type*.
|
| 36 |
+
|
| 37 |
+
For every integer-class type `I`, let `B(I)` be a hypothetical extended
|
| 38 |
+
integer type of the same signedness with the smallest width
|
| 39 |
+
[[basic.fundamental]] capable of representing the same range of values.
|
| 40 |
+
The width of `I` is equal to the width of `B(I)`.
|
| 41 |
+
|
| 42 |
+
Let `a` and `b` be objects of integer-class type `I`, let `x` and `y` be
|
| 43 |
+
objects of type `B(I)` as described above that represent the same values
|
| 44 |
+
as `a` and `b` respectively, and let `c` be an lvalue of any integral
|
| 45 |
+
type.
|
| 46 |
+
|
| 47 |
+
- For every unary operator `@` for which the expression `@x` is
|
| 48 |
+
well-formed, `@a` shall also be well-formed and have the same value,
|
| 49 |
+
effects, and value category as `@x` provided that value is
|
| 50 |
+
representable by `I`. If `@x` has type `bool`, so too does `@a`; if
|
| 51 |
+
`@x` has type `B(I)`, then `@a` has type `I`.
|
| 52 |
+
- For every assignment operator `@=` for which `c @= x` is well-formed,
|
| 53 |
+
`c @= a` shall also be well-formed and shall have the same value and
|
| 54 |
+
effects as `c @= x`. The expression `c @= a` shall be an lvalue
|
| 55 |
+
referring to `c`.
|
| 56 |
+
- For every binary operator `@` for which `x @ y` is well-formed,
|
| 57 |
+
`a @ b` shall also be well-formed and shall have the same value,
|
| 58 |
+
effects, and value category as `x @ y` provided that value is
|
| 59 |
+
representable by `I`. If `x @ y` has type `bool`, so too does `a @ b`;
|
| 60 |
+
if `x @ y` has type `B(I)`, then `a @ b` has type `I`.
|
| 61 |
+
|
| 62 |
+
Expressions of integer-class type are explicitly convertible to any
|
| 63 |
+
integral type. Expressions of integral type are both implicitly and
|
| 64 |
+
explicitly convertible to any integer-class type. Conversions between
|
| 65 |
+
integral and integer-class types do not exit via an exception.
|
| 66 |
+
|
| 67 |
+
An expression `E` of integer-class type `I` is contextually convertible
|
| 68 |
+
to `bool` as if by `bool(E != I(0))`.
|
| 69 |
+
|
| 70 |
+
All integer-class types model `regular` [[concepts.object]] and
|
| 71 |
+
`totally_ordered` [[concept.totallyordered]].
|
| 72 |
+
|
| 73 |
+
A value-initialized object of integer-class type has value 0.
|
| 74 |
+
|
| 75 |
+
For every (possibly cv-qualified) integer-class type `I`,
|
| 76 |
+
`numeric_limits<I>` is specialized such that:
|
| 77 |
+
|
| 78 |
+
- `numeric_limits<I>::is_specialized` is `true`,
|
| 79 |
+
- `numeric_limits<I>::is_signed` is `true` if and only if `I` is a
|
| 80 |
+
signed-integer-class type,
|
| 81 |
+
- `numeric_limits<I>::is_integer` is `true`,
|
| 82 |
+
- `numeric_limits<I>::is_exact` is `true`,
|
| 83 |
+
- `numeric_limits<I>::digits` is equal to the width of the integer-class
|
| 84 |
+
type,
|
| 85 |
+
- `numeric_limits<I>::digits10` is equal to
|
| 86 |
+
`static_cast<int>(digits * log10(2))`, and
|
| 87 |
+
- `numeric_limits<I>::min()` and `numeric_limits<I>::max()` return the
|
| 88 |
+
lowest and highest representable values of `I`, respectively, and
|
| 89 |
+
`numeric_limits<I>::lowest()` returns `numeric_limits<I>::{}min()`.
|
| 90 |
+
|
| 91 |
+
A type `I` is *integer-like* if it models `integral<I>` or if it is an
|
| 92 |
+
integer-class type. A type `I` is *signed-integer-like* if it models
|
| 93 |
+
`signed_integral<I>` or if it is a signed-integer-class type. A type `I`
|
| 94 |
+
is *unsigned-integer-like* if it models `unsigned_integral<I>` or if it
|
| 95 |
+
is an unsigned-integer-class type.
|
| 96 |
+
|
| 97 |
+
`is-integer-like<I>` is `true` if and only if `I` is an integer-like
|
| 98 |
+
type. `is-signed-integer-like<I>` is `true` if and only if I is a
|
| 99 |
+
signed-integer-like type.
|
| 100 |
+
|
| 101 |
+
Let `i` be an object of type `I`. When `i` is in the domain of both pre-
|
| 102 |
+
and post-increment, `i` is said to be *incrementable*. `I` models
|
| 103 |
+
`weakly_incrementable<I>` only if
|
| 104 |
+
|
| 105 |
+
- The expressions `++i` and `i++` have the same domain.
|
| 106 |
+
- If `i` is incrementable, then both `++i` and `i++` advance `i` to the
|
| 107 |
+
next element.
|
| 108 |
+
- If `i` is incrementable, then `addressof(++i)` is equal to
|
| 109 |
+
`addressof(i)`.
|
| 110 |
+
|
| 111 |
+
[*Note 1*: For `weakly_incrementable` types, `a` equals `b` does not
|
| 112 |
+
imply that `++a` equals `++b`. (Equality does not guarantee the
|
| 113 |
+
substitution property or referential transparency.) Algorithms on weakly
|
| 114 |
+
incrementable types should never attempt to pass through the same
|
| 115 |
+
incrementable value twice. They should be single-pass algorithms. These
|
| 116 |
+
algorithms can be used with istreams as the source of the input data
|
| 117 |
+
through the `istream_iterator` class template. — *end note*]
|
| 118 |
+
|