Next: Comparisons involving `poly_int`

, Previous: Overview of `poly_int`

, Up: poly_int [Contents][Index]

`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, `

has no indeterminates
and so degenerates to a compile-time constant of type `T`>`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<`

as well, regardless of
the current target’s `n`, `T`>`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, `

to `T`>`T` when compiling target-specific translation units.