4 ms·

"invalid" is relative to a spec. You are writing in a language (usually) that specify what guarantee you get.

• MaulingMonkey 12y ago
  Specs have holes and ambiguities. And C++ in general likes to avoid guarantees to my frustration. In this case, we're not even guaranteed which specs apply. In this case, the C++ standard references the C standard contains the (optional/normative) Annex F referencing the IEC 60559 standard (which has the same content as IEEE 754). Annex F defines float and double in terms of the IEC 60559 single & double formats... and the standard C++ operators in terms of their IEC 60559 counterparts... and recommends long double be implemented as an extended double format (such as the 80-bit format commonly used by x86.) Annex F also mentions allowed optimizations, disallowed optimizations (involving various corner cases, rounding modes, implementation defined signaling exceptions, etc. ad infinitum). I don't see temporarily handling a double as an IEC 60559 Extended Double format anywhere on the allowed optimizations list, but I can't tell for certain if it runs afoul of any of the specifically disallowed optimizations of Annex F either. I'm guessing /fp:strict is meant to imply strict compliance with some standard, but MSDN talks about /fp:precise maintaining enough precision to be within "strict ANSI compliance" as well (under Annex F? Or perhaps they mean within Annex E's epsilon precision requirements...) MSVC (2008-2013) doesn't appear to define __STDC_IEC_559__ which would definitively bind it to Annex F, but it does define std::numeric_limits<...>::is_iec559 = true for float/double/long double, which at least binds it to IEC 60559...