Boost logo

Boost :

From: Matthias Troyer (troyer_at_[hidden])
Date: 2003-02-05 10:11:56

On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
> 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?

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.

> 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...

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at