GDC release 0.23

[Sean Kelly]

Anders F Björklund wrote:
> Don Clugston wrote:
> 
>>> Older versions of PPC operating systems used 64-bit for "long double",
>>> newer versions use 128-bit. Both are still in use, so we won't know.
>>
>> Ugh. That's really horrible.
> 
> It's called progress :-)

*snicker*

>>> And since the D "real" type simply maps over to C/C++ "long double",
>>> it means that it will be either 64-bit, 80-bit or 128-bit. Varying.
>>
>> We've got to keep that piece of lunacy out of D somehow. Could we 
>> define it as __longdouble or something? (Ideally only for PPC, so that 
>> error messages remain sensible on other platforms).
>>
>> At least in D, we can static-if an alias or typedef on the basis of 
>> mant_dig.
> 
> I'll let David decide which one wins: D real === C long double, or
> the definition of "largest hardware implemented floating point size"

I think the salient point is "hardware implemented."  However, as David 
mentioned, C compatibility is important as well.  Perhaps it would be 
best to restrict real to the actual maximum size supported in hardware 
and to add an alias, typedef, struct, whatever, to allow C interop. 
This would be similar to what we already have to do for interfacing with 
C long/ulong across 32 and 64 bit platforms.  My only question here, 
then, is how translation might be performed between a 64 bit "hardware" 
real and a 128 bit "software" real?  And is this distinction truly 
useful?  Given the description of the current 128 bit doubles, I can't 
see ever wanting to use them.


Sean