<p dir="ltr"><br>
On 4 Jul 2014 13:10, "Daniel Murphy via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> "Walter Bright"  wrote in message news:lp26l3$qlk$1@digitalmars.com...<br>
><br>
><br>
>> Per the D spec, 'real' will be the longest type supported by the native hardware.<br>
><br>
><br>
> 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.<br>

></p>
<p dir="ltr">FP types are fixed.  float is 32bit, double 64bit.<br></p>
<p dir="ltr">><br>
>> 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.<br>
><br>
><br>
> 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, but luckily relatively few interfaces actually use long double. </p>

<p dir="ltr">What 's the mangling problem with long double? There's only *one* long double.</p>