Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-02-25 11:43:00

> -----Original Message-----
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> Sent: Monday, February 25, 2002 8:24 AM
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: RE: [boost] Re: Design for a file system library
> At 09:58 PM 2/24/2002, Jeff Garland wrote:
> >> Seems like we should hold off on time until Jeff Garland and his group
> >get
> >> their time library proposal done.
> >
> >This hasn't been fully settled, but the generic time has the ability to
> >extract
> >the date, and the time of day (hours, minutes, seconds and fractions of a
> >second). The resolution of the fraction of seconds is something that can
> >be
> >adjusted so if we need nanoseconds and the system can provide them then
> >that's
> >we'll do. The fractions of a second approach allows most code to handle
> >the
> >sub-second stuff generically for different resolutions. However,
> >nanosecond
> >resolution won't be supported on many platforms, so we would need to play
> >some
> >tricks (like set nanoseconds to zero on all non-supporting platforms or
> use
> >a
> >templated time type to adjust the resolution by platform) to deal with
> >this.
> I guess what I'm saying is that at least two potential Boost libraries
> (threads and filesystems) need some notion of time that goes beyond
> anything now in the standard, so we really need a Boost-now and
> standard-later solution so developers don't have to keep reinventing the
> wheel.

I agree. Since GDTL supports the concept of multiple time systems for different
purposes, I'd like to gather the specific requirements for threads and
filesystems. Here's what I see from the current file discussion and the current
threads library:

* represent time durations (eg: 01:02:03.0000001) (thread only)
* convert durations to counts a different resolutions (micro, nano, etc) (thread
* represent time points (eg: 2002-02-25 08:00:00.0000001) (both)
* represent time points with resolutions down to nano-seconds (both)
* provisions for platforms that don't support nano-seconds (both)
* get the current time point from the clock (both)
* add durations to a time point (thread only)
* compare timepoints (eg: > < == !=) (both)
* compare durations (eg: > < == !=) (thread only)
* ability output a time point to a string (file only -- clients)
* a desire to minimize the dependencies

Some things you DON'T need:
* ability to represent time points prior to 1970
* ability to represent 'special values': not-a-time, infinities
* ability to output time durations to string (except maybe for debugging)
* ability to parse a string and build a time point or duration



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