25 Iterators library [iterators]

The weakly_incrementable concept specifies the requirements on types that can be incremented with the pre- and post-increment operators.

The increment operations are not required to be equality-preserving, nor is the type required to be equality_comparable.

A type I is an integer-class type if it is in a set of implementation-defined types that behave as integer types do, as defined below.

The range of representable values of an integer-class type is the continuous set of values over which it is defined.

For any integer-class type, its range of representable values is either $-2^{N-1}$ to $2^{N-1}-1$ (inclusive) for some integer N, in which case it is a signed-integer-class type, or 0 to $2^N-1$ (inclusive) for some integer N, in which case it is an unsigned-integer-class type.

In both cases, N is called the width of the integer-class type.

The width of an integer-class type is greater than that of every integral type of the same signedness.

A type I other than cv bool is integer-like if it models integral<I> or if it is an integer-class type.

An integer-like type I is signed-integer-like if it models signed_integral<I> or if it is a signed-integer-class type.

An integer-like type I is unsigned-integer-like if it models unsigned_integral<I> or if it is an unsigned-integer-class type.

For every integer-class type I, let B(I) be a unique hypothetical extended integer type of the same signedness with the same width ([basic.fundamental]) as I.

For every integral type J, let B(J) be the same type as J.

Expressions of integer-class type are explicitly convertible to any integer-like type, and implicitly convertible to any integer-class type of equal or greater width and the same signedness.

Expressions of integral type are both implicitly and explicitly convertible to any integer-class type.

Conversions between integral and integer-class types and between two integer-class types do not exit via an exception.

The result of such a conversion is the unique value of the destination type that is congruent to the source modulo $2^N$, where N is the width of the destination type.

Let a be an object of integer-class type I, let b be an object of integer-like type I2 such that the expression b is implicitly convertible to I, let x and y be, respectively, objects of type B(I) and B(I2) as described above that represent the same values as a and b, and let c be an lvalue of any integral type.

An expression E of integer-class type I is contextually convertible to bool as if by bool(E != I(0)).

All integer-class types model regular ([concepts.object]) and three_way_comparable<strong_ordering> ([cmp.concept]).

A value-initialized object of integer-class type has value 0.

For every (possibly cv-qualified) integer-class type I, numeric_limits<I> is specialized such that each static data member m has the same value as numeric_limits<B(I)>​::​m, and each static member function f returns I(numeric_limits<B(I)>​::​f()).

For any two integer-like types I1 and I2, at least one of which is an integer-class type, common_type_t<I1, I2> denotes an integer-class type whose width is not less than that of I1 or I2.

If both I1 and I2 are signed-integer-like types, then common_type_t<I1, I2> is also a signed-integer-like type.

is-integer-like<I> is true if and only if I is an integer-like type.

is-signed-integer-like<I> is true if and only if I is a signed-integer-like type.

Let i be an object of type I.

When i is in the domain of both pre- and post-increment, i is said to be incrementable.

I models weakly_incrementable<I> only if

• (14.1)
  The expressions ++i and i++ have the same domain.
• (14.2)
  If i is incrementable, then both ++i and i++ advance i to the next element.
• (14.3)
  If i is incrementable, then addressof(++i) is equal to addressof(i).

Recommended practice: The implementation of an algorithm on a weakly incrementable type should never attempt to pass through the same incrementable value twice; such an algorithm should be a single-pass algorithm.