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