Of course this is off-topic here, but it happens to be a pet peeve of
mine. And since a substantial fraction of comp.lang.c++ uses
Microsoft's Visual C++ compiler, they may be affected by this issue.
Hardly. Microsoft decided to offer the customer a choice of hardware
from competing vendors in order to run Windows NT. Microsoft
even-handedly made sure that their compiler adhered to industry
standard floating point format (IEEE) rather than show blatant
favoritism toward a dominant supplier by catering to its proprietary
chip.
That's quite nice, but the IEEE defines an "IEEE 754 Double-Extended"
format that is just as much part of the standard as the 32-bit
"Single" and 64-bit "Double" floating point formats. Now it just so
happens that the IEEE 754 standard was based largely on Intel's work
in developing the x86 math coprocessor and later FPU, but that's
immaterial. The 80-bit "Double-Extended" format is fully a part of
the IEEE 754 standard, even though its implementation is optional.
As for compatibility, everyone expects the C/C++ float and double
types to use the IEEE 754 formats, and Microsoft had to do nothing at
all to keep their 32-bit compilers compatible with user's
expectations, as their 16-bit compilers had been.
Microsoft didn't "take away" anything, since the customer is not
That is not true at all. I had C programs that delivered accurate
results in Microsoft C compilers from MS-DOS version 5.x through
Visual C++ 1.52, with or without floating point hardware. When
recompiled with Visual C++ 4.0, the first 32-bit version I used, they
delivered different and inaccurate results.
From my point of view, they certainly "took away" accuracy and
precision from the long double data type, features that had existed in
their 16-bit predecessors, and that were still right their in the
processor hardware.
obligated to use their compiler, and Intel's floating point chip is
They have at most times in the past made every effort to ensure that
the maximum possible percentage of x86 Windows programmers used their
compiler. Or so it appears to me, you may disagree. Can you provide
an URL to a link on their web site mentioning other compilers as a
possibility to those who want the 80 bit format back?
still capable of 80-bit precision. Nor does either the C or C++
standard require any specific level of precision.
I am well aware of the fact that neither language requires long double
to have any more precision and range than double. I am also well
aware of the fact that the IEEE "Double" format exceeds the minimum
requirements of C and C++ by a considerable margin.
Incidentally, Windows NT never ran on an ARM processor. It did run and
continues to run on the PowerPC (to power the XBox 360).
Is there any other non x86 architecture running a version of Windows
other then CE these days, or anyone other than Microsoft running it on
a PowerPC?
Consistent, verifiable floating point results across platforms is
better engineering than apparently more precise results reproducible on
a single platform - especially when the accuracy of those results is
open to doubt (as the Pentium division bug superbly demonstrated).
This is utter nonsense. They deliberately deprived the programmer of
the ability to make the choice between maximum accuracy permitted by
the hardware and maximum comparability. Some who use the long double
type know exactly why they use it and what they expect from it.
Generally, those who don't know what they are doing generally just use
float or double.
Of course, hardcore Intel fans can always use Intel's C/C++ compiler -
which apparently costs the company nothing to write. Intel does give it
away for free. But anyone hoping for a free PowerPC compiler from Intel
is probably out of luck.
How does this square with Microsoft's cramming support for MMX, SIMD,
SIMD2, etc., into Visual C++, when these features aren't available on
"all" those other architectures running NT and its descendents these
days?
"Sound engineering" does not necessarily equate to doing right by the
customer. In this case, Microsoft did do the right thing.
"Sound engineering" means leaving the engineering decisions up to the
engineer dealing with the requirements of the particular situation, or
application in this case.
"Sound engineering" does not mean denying the engineer/programmer the
opportunity to make a decision by deciding for him/her that accuracy
and precision were not as important as Microsoft's idea of
portability. The result is that Microsoft Visual C++ is literally
unsuitable for certain types of serious scientific and engineering
applications.
They could quite easily have documented that long double was not
portable across Windows implementations, whereas float and double
were.
There are numerous discussions available online about the harmful
effects of denying the use of the full precision available. For one
such, see
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF