On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
The current CVS version uses long long as default even if long is 64 bit. I have thus patched my version of cstdint.hpp to typedef int64_t to long, whicha voids some of the problems with long long.The lack of support of standard library functions associated with long long is a problem on other platforms and other functions (eg: std::abs). This has been a headache for me using the int64_t in date-time.So I presume that the boost::int64_t is typedefed to long for the Cray now?
I am looking into it but already have a conjecture. When using signed 64 bit integers the Cray compiler (with optimization turned on) uses the floating point units to actually perform the operations in 46 bit arithmetic. This speeds up things but causes compatibility problems. In the case of the jam sources we could avoid this "optimization" by using unsigned types. Is it possible to use an unsigned integer here to avoid similar problems?Curiously the one failure for date-time was in handling of big time durations. The failure is probably an overflow problem, which can happen if you try to use a plain 32-bit integer to get nano-second resolutions and large time durations. Nano-second resolution is the default configuration for the library and it normally uses a 64-bit type for efficient calculation...
Matthias
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
