Re: [Boost-users] [datetime] Parametrization of class datetime.

From: Seweryn Habdank-Wojewódzki (habdank_at_[hidden])
Date: 2006-05-26 16:58:32

Hi

Jeff Garland wrote:

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

Thanks a lot for explanations. I will try to work with other types and try to
include GMP or other BigNums.

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

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

I will look at them.
 
> 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.

Yes it is true. But from other hand there are so many "infinity" calendars,
that could be implemented in programs.

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

Yes I understand this.

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

Once more thanks, I will work with it.

Best regards.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/