10.2 Consequences of using poly_int ¶

The two main consequences of using polynomial sizes and offsets are that:

• there is no total ordering between the values at compile time, and
• some operations might yield results that cannot be expressed as a poly_int.

For example, if x is a runtime invariant, we cannot tell at compile time whether:

3 + 4x <= 1 + 5x

since the condition is false when x <= 1 and true when x >= 2.

Similarly, poly_int cannot represent the result of:

(3 + 4x) * (1 + 5x)

since it cannot (and in practice does not need to) store powers greater than one. It also cannot represent the result of:

(3 + 4x) / (1 + 5x)

The following sections describe how we deal with these restrictions.

As described earlier, a poly_int<1, T> has no indeterminates and so degenerates to a compile-time constant of type T. It would be possible in that case to do all normal arithmetic on the T, and to compare the T using the normal C++ operators. We deliberately prevent target-independent code from doing this, since the compiler needs to support other poly_int<n, T> as well, regardless of the current target’s NUM_POLY_INT_COEFFS.

However, it would be very artificial to force target-specific code to follow these restrictions if the target has no runtime indeterminates. There is therefore an implicit conversion from poly_int<1, T> to T when compiling target-specific translation units.