On 7/4/2014 5:06 AM, Daniel Murphy wrote:
"Walter Bright" wrote in message news:[email protected]...
Per the D spec, 'real' will be the longest type supported by the native
hardware.
So if you were targeting a processor with only soft-float real would be
undefined? Fixing the widths of the integers was a great idea, and we really
should have done the same with the floating point types. We could easily have a
library alias for what real currently means.
Again, I expect the implementor for Platform X to be able to make a solid
judgement on what to do for that platform that makes the most sense.
Not only that, a marquee feature of D is interoperability with C. We'd need an
AWFULLY good reason to throw that under the bus.
Unfortunately it's a useless definition for portable interop with C++. real
needs to always match the size and mangling of long double unless you want to
stick workarounds all over the bindings. We have related problems with
char/char/char and long/longlong/size_t,
Such problems disappear when common sense is applied.
but luckily relatively few interfaces actually use long double.
I really do not understand what the big problem is. It's trivial to interface
with C code on Linux that accepts long doubles on all platforms D currently
supports.
