> > 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
Seems like a dangerous tradeoff... > 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? I suppose anything would be possible, but it would be difficult. It is a signed type since we want to be able to have negative time durations. One possible answer is that we could turn down the resolution to microseconds by removing: <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG from the Jamfile. Although actually what we really want to do is make a selection based on the platform macro in the Jamfile. I don't know how to do this, but I'm sure someone does :-) Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
