From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-06 19:03:02
On Fri, 04 Mar 2005 16:09:55 -0500, James Fowler wrote
A few more thoughts here. I think the conversion to Boost date-time types
gets you most of what you want here:
> * interface issues for capturing durations
> o consistent, portable representation
date-time time_duration does this.
> o normalized conversion(s) for use in external expressions
> (i.e., as double representing seconds)
I find the lossy arithmetic associated with doubles a non-starter for
date-time applications. Boost date-time uses integer types and provides
fractional seconds breakdowns for time_durations.
> o support for internal expressions (add, subtract, compare)
date-time time_duration does this.
http://www.boost.org/doc/html/date_time/posix_time.html#date_time.posix_time.time_duration
> o variety of use cases for establishing boundary moments
> + constructor starts, destructor stops (and stores to
> target provided to constructor)
> + manual start / pause / continue / stop / restart
> (clear accumulated duration)
> + auxiliary class (takes reference to instance of
> duration, constructor calls start|continue, destructor
> calls stop)
> + and numerous other variations on the theme...
These would be additions to the current timer interface. See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer
for a proposal on how this might look. Please add / modify as you see fit.
> o support for iostreams
Supported by time_duration.
> o represented as a class (possibly templatized on mechanism
> for actual time capture)
> + internal representation of
> start_time/stop_time/accumulated duration can be based
> on portable POD types
Yep. Boost date-time is quite portable because it uses types like
boost::int64_t under the hood.
> * interface for capturing high resolution time
> o can be very challenging to balance:
> + resolution (as high possible??? !!!)
> + reliability and accuracy (otherwise resolution doesn't
> mean much...)
> + efficiency (all this with zero runtime overhead
> please, and fetch me a fresh cup of coffee while
> you're at it)
> o variations in interface
> + hard to find one ideal portable API to build on, lots
> of choices
> # ACE has some nice timer wrappers
>
Dealing with unstable clocks is a nasty problem. That said, with date-time
it's been isolated so that if you can write a better clock for a platform we
should be able to plug it into the new timer framework.
>...snip...a whole bunch more stuff
>....
> Hopefully this gives a taste of the complexities surrounding the
> seemingly simple task of getting a precise representation of "now".
Agreed. I'm hoping if we build on boost date-time it will be much easier
though. Basically it should be down to writing new and unique clocks with
different properties that plug into the timer.
Jeff