Strategies for portability across CommonPoint platforms

• Use numerical functions and classes from Numerics.h and FPEnvironment.h. Use random number generators and special integer operations from RandomNumber.h, IntegerMath.h, and PrimitiveTypes.h.
• Use types float and double for long-term storage of floating-point data. Don't stream long double data by decomposing values into integral subfields and streaming those to and from storage.
• Use types float_t and double_t for temporary variables. Though they might be wider than float and double, respectively, don't depend on that. Don't stream these types.
• Use the type long double for its extra precision only. Don't depend on greater exponent range. Be aware that on some platforms long double operations may be much slower than float and double operations.

TIP In cases requiring extra range in long double, consider supporting two implementations, a straightforward one for platforms whose long double type offers extra range as well as precision, and a more carefully programmed one for platforms offering the exponent range of double and no more.

• Use explicit casting to ensure that narrow subexpressions are computed to a wider type.
• Use the proposed Floating-Point C Extensions features in Numerics.h and FPEnvironment.h. Use the fenv_access pragma when manipulating the environment. Don't depend on compiler support of hexadecimal floating constants, but do expect sufficiently accurate binary-decimal conversion that any desired binary value can be fully specified by 9 digits for type float and 17 digits for type double.

TIP If you develop on a platform supporting hexadecimal floating constants, isolate them in one or more header files in the event you should need to express them in decimal form.

• Use the underflow flag to defend against loss of precision in tiny numbers when the loss matters. Don't assume that all compilers will raise underflow in precisely the same circumstances. See "Alternatives" on page 219 for more details.
• Assume that the elementary functions are accurate to within a few units in the last place of the result. Assume that they're monotonic where appropriate, that they remain within their mathematical range (for example, for all finite x), and that they satisfy mathematical identities such as to within roundoff.
• Don't depend on the byte order of numbers in memory. Use stream operators for file I/O and use manipulation functions such as SignBit, Logb, and Scalb to decompose a floating-point value into its constituent sign, exponent, and significand.
• Use quiet NaNs, as supported by the system.
• Don't depend on the value of an integral result when the mathematical result cannot be held exactly in the integral type. The invalid flag is raised, but the result is platform-dependent.