No doubt about what you say, but this question remains.
If f64 variables are now a structure-type rather than just
an alias for "double", what happens in the 58493 places
where my code passes f64 variables into functions?
I am worried about library and system functions that
expect conventional "double" arguments.
Pedro Izecksohn wrote:
>
> --- maxreason <[EMAIL PROTECTED]> wrote:
>>
>> 1: From an original software package I wrote long ago in
>> another language, I could declare the value of an f64 AKA
>> "double" precision floating point constant with:
>>
>> $$PI = 0d400921FB54442D18
>>
>> where the "0d" prefix says "this is a double precision value
>> input in hexadecimal". I have about 200 of these, because I was
>> able to compute bit-accurate values for many fundamental math
>> constants, and found that assigning ascii-decimal values to the
>> constant often led to 2~5 bit errors (in the ascii->double code).
>>
>> That's very nice, but I assume C simply lacks such a nice feature.
>> So, my question is - what alternatives can you come up with?
>>
>> The crappy "solution" in the windoze version of my 3D engine
>> is the following:
>>
>> const s64 MATH_bit_PI = 0x400921FB54442D18;
>> const f64 MATH_PI = (*(f64*)&MATH_bit_PI);
>>
>> Though this is truly revolting, it works on visual studio.
>> Yes, I have typedefs that define s64 and f64 from the long
>> conventional type names.
>>
>
> Read:
> /usr/include/math.h
> /usr/include/bits/huge_valf.h
>
> A solution:
> #include <stdint.h>
>
> typedef union {
> int64_t i;
> double d;
> } f64;
>
> const f64 MATH_PI = {0x400921FB54442D18LL};
>
> Any doubt left?
>
--
View this message in context:
http://www.nabble.com/problems-porting-3D-engine-from-windoze-to-linux-tp15108399p15110035.html
Sent from the C-prog mailing list archive at Nabble.com.
