Menu
▾
▴
#130 64-bit, M_PI, and others
This patch introduces the following features:
1) Works around config.h busted-ness from Daniel KO's change. This may no longer be needed.
2) Makes M_PI appear correctly from the Microsoft headers, and deals with dReal cast issues because of that.
3) Adds 64-bit support for OPCODE. Note that this support is functional, but not optimal. There are asserts to catch if some assumptions I made are wrong.
4) Makes sure that GIMPACT code is not built if the option is not defined in config.h. GIMPACT is not 64-bit clean.
Note that this patch is quite hacky and dirty, but some bits may still be useful.
output of svn diff for 64-bit support
Logged In: YES
user_id=14028
Originator: NO
A general remark: the patch seems to contain whitespace edits?
It makes the patch a bit harder to read.
It seems Daniel change has been reverted, so I take it 1) is obsolete.
I suspect that 2) can be solved more elegantly.
What happens if you remove the conditional in common.h guarding the redef of M_PI ?
REAL(3.14159) evaluates to 3.14159f on single prec, so it should fix your issue?
Maybe do
ifdef WIN32
define M_PI REAL(3.14159)
endif
I will address 3) and 4) at a later time.
Bram
Logged In: YES
user_id=1076376
Originator: YES
There is some benefit in letting M_PI come from the standard library, because then it will presumably be exactly the same value used by the internal implementation. However, we can probably live without that.
If you don't want to define _USER_MATH_DEFINES, then the alternative should be to:
include <math.h>
if !defined(M_PI)
if defined(dSINGLE)
define M_PI 3.1415927f
else
define M_PI 3.1415926535...
endif
endif
Driving M_PI on WIN32 is wrong, as someone might define _USE_MATH_DEFINES for other reasons on the command line. Also, the (dReal) casts are necessary for the cases where M_PI come from system headers on other systems, and are always double precision. Thus, I think my solution is actually preferable overall.
Logged In: YES
user_id=14028
Originator: NO
M_PI part of patch has been applied as rev 1351 of trunk.
Logged In: YES
user_id=1481948
Originator: NO
As far as I can tell: Parts [1] and [2] are integrated with the trunk.
Is the 64-bit stuff in [3] and [4] still valid? Should this patch be tidied up and re-submitted?
Logged In: YES
user_id=1076376
Originator: YES
Yes, the content of 3 and 4 is still needed. I don't know if it will still apply cleanly, but I think it may.
Closed since this seems to be outdated.