From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-25 00:25:53
Seweryn Habdank-Wojewódzki wrote:
> Hi
>
> Beth Jacobson wrote:
>
>
>>ticks()/ticks_per_second() will give you the correct number of seconds.
>
>
> I know it.
>
>
>>I think Seweryn was talking about this:
>>long total_seconds()
>>^^^^
>
>
> Yes. Exactly.
>
>
>>You can have a time duration of 200 years, but the number of seconds in
>>200 years is too large to fit in a long, so the total_seconds() function
>>won't work.
>
>
> Exactly.
>
>
>>According to the doc, ticks() returns a boost::int64_t. Couldn't
>>total_seconds(), total_milliseconds(), etc. do the same?
>
> Yes. So the question is if there is any possibility to parametrize it with
> other tyle bigger than long.
>
Sorry for the delay on the reply. I didn't understand the issue from
your first mail. Yes, it can be trivially done. 'long' is really just
what the docs say. The code is actually in terms of a template that
defaults to boost::int32_t. This can be trivially changed by as follows:
Add boost::int64_t as the last parameter in templates in
date_time/time_resolution_traits.hpp::133 and ::134 So new is:
typedef time_resolution_traits<time_resolution_traits_adapted64_impl,
micro, 1000000, 6, boost::int64_t > micro_res;
// ^^^^^^^^^^^^^^
typedef time_resolution_traits<time_resolution_traits_adapted64_impl,
nano, 1000000000, 9, boost::int64_t > nano_res;
// ^^^^^^^^^^^^^^
Of course, if you change it to BigInt that should work as well. But
honestly, if you are going the BitInt route there are a few other
parameters you would want to update to get more consistent behavior.
> In fact there is no bignum library in boost. Probably reason is because GMP is
> very good. But sometimes there is important to calculate time distances bigger
> than numeric_limits<long>::max()/(365*24*60*60) what is more less 68 years.
There is a bitInt in the sandbox by Ron Garcia which has the option to
wrap around gmp -- not sure if it will ever be submitted.
In any case, the design of date_time supports this flexibility, but a
configuration using a BigInt has been tried. Half the reason I wrote
the library was that I was frustrated with date_time systems with a
fixed internal representation. So many of them fix the representation at
some arbitrarily sized number -- like 32 bits. Unfortunately, one day
you need something bigger -- oh, sorry library rewrite. It's a classic
example of why OO fails in some cases -- a supposedly internal design
decision that ends up dramtically limiting the user options. As it is,
the library is routinely built and tested with 2 variations: 96 bit
internal times and 64 bit internal times. Other options are just a few
keystrokes away.
If you have a real use case where this would be used I'd be willing to
work thru how to set it up. There may be some troubles with infinite
precision numbers and how they interact with the
infinity/not-a-date-time handling, but otherwise it shouldn't be too hard.
Jeff