Next: Comparisons involving <code>poly_int</code>, Previous: Overview of <code>poly_int</code>, Up: poly_int

### 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.