| ## Safe Numerics

### Using safe_range and safe_literal

When trying to avoid arithmetic errors of the above type, programmers will select data types which are wide enough to hold values large enough to be certain that results won't overflow, but are not so large as to make the program needlessly inefficient. In the example below, we presume we know that the values we want to work with fall in the range [-24,82]. So we "know" the program will always result in a correct result. But since we trust no one, and since the program could change and the expressions be replaced with other ones, we'll still use the `loose_trap_policy` exception policy to verify at compile time that what we "know" to be true is in fact true.

    #include <iostream>

    #include <boost/safe_numerics/safe_integer_range.hpp>
    #include <boost/safe_numerics/safe_integer_literal.hpp>
    #include <boost/safe_numerics/exception.hpp>
    #include <boost/safe_numerics/native.hpp>
    #include "safe_format.hpp" // prints out range and value of any type

    using namespace boost::safe_numerics;

    // create a type for holding small integers in a specific range
    using safe_t = safe_signed_range<
        -24,
        82,
        native,           // C++ type promotion rules work OK for this example
        loose_trap_policy // catch problems at compile time
    >;

    // create a type to hold one specific value
    template<int I>
    using const_safe_t = safe_signed_literal<I, native, loose_trap_policy>;

    // We "know" that C++ type promotion rules will work such that
    // addition will never overflow. If we change the program to break this,
    // the usage of the loose_trap_policy promotion policy will prevent compilation.
    int main(int, const char *[]){
        std::cout << "example 83:\n";

        constexpr const const_safe_t<10> x;
        std::cout << "x = " << safe_format(x) << std::endl;
        constexpr const const_safe_t<67> y;
        std::cout << "y = " << safe_format(y) << std::endl;
        const safe_t z = x + y;
        std::cout << "x + y = " << safe_format(x + y) << std::endl;
        std::cout << "z = " << safe_format(z) << std::endl;
        return 0;
    }

- ``safe_signed_range`` defines a type which is limited to the indicated range. Out of range assignments will be detected at compile time if possible (as in this case) or at run time if necessary.

- A safe range could be defined with the same minimum and maximum value effectively restricting the type to holding one specific value. This is what `safe_signed_literal` does.

- Defining constants with `safe_signed_literal` enables the library to correctly anticipate the correct range of the results of arithmetic expressions at compile time.

- The usage of ``loose_trap_policy`` will mean that any assignment to z which could be outside its legal range will result in a compile time error.

- All safe integer operations are implemented as constant expressions. The usage of `constexpr` will guarantee that `z` will be available at compile time for any subsequent use.

- So if this program compiles, it's guaranteed to return a valid result.

The output uses a custom output manipulator, `safe_format`, for safe types to display the underlying type and its range as well as current value. This program produces the following run time output.

    example 83:
    x = <signed char>[10,10] = 10
    y = <signed char>[67,67] = 67
    x + y = <int>[77,77] = 77
    z = <signed char>[-24,82] = 77

Take note of the various variable types:

- `x` and `y` are safe types with fixed ranges which encompass one single value. They can hold only that value which they have been assigned at compile time.

- `The sum x + y can also be determined at compile time.`

- The type of z is defined so that It can hold only values in the closed range -24,82. We can assign the sum of x + y because it is in the range that `z` is guaranteed to hold. If the sum could not be be guaranteed to fall in the range of `z`, we would get a compile time error due to the fact we are using the `loose_trap_policy` exception policy.

All this information regarding the range and values of variables has been determined at compile time. There is no runtime overhead. The usage of safe types does not alter the calculations or results in anyway. So `safe_t` and `const_safe_t` could be redefined to `int` and `const int` respectively and the program would operate identically - although it might We could compile the program for another machine - as is common when building embedded systems and know (assuming the target machine architecture was the same as our native one) that no erroneous results would ever be produced.