Boost logo

Boost :

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.

> 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

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.


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