RE: [boost] boost.timer

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-10-31 20:02:34

At 05:15 PM 10/31/2001, Jeff Garland wrote:
 >
 >
 >> I'm inclined to think the solution may not be to try to fix timer, but
 >> to specify a new timing library with much more precise semantics.
 >>
 >> If Jeff Garland is reading this, I'd be curious if his date and time
 >> classes would solve the problem.  I know they can handle very large
 >> granularity (100 year, for example, used in measuring geological time), 

 >but
 >> I don't remember if they can handle very small time periods, and what
 >they
 >> do if the hardware timers can't deliver the precision desired.
 >
 >Yes, the Time part of the Generic Date Time Library (GDTL) has an
 >adjustable precision.  So you can have a time_duration with a precision
 >to nano-seconds (or whatever you want to pay for).  The real problem,
 >however, is what the hardware/software clocks can actually deliver.
 >My library doesn't do anything to address that.

If there is some way to detect that the user is asking for something the 
platform can't deliver, that would certainly be a useful 
diagnostic.  Although you might be doing time calculations on data 
generated elsewhere, so the fact that the current platform's clock's 
couldn't resolve to the precision required wouldn't be a problem.

 >  Just as an aside,
 >I don't have a timer in GDTL at this point, but it would probably be
 >a logical home for this functionality...

In particular, it would be nice to have a full fledged timer to replace the 
xtime placeholder Bill Kempf has in Boost.Threads.

But while it might be useful to give a bit of thought to how those timer 
needs would play out in relation to the GDTL, I'd hate to see that exercise 
cause much delay in submitting the GDTL to Boost for initial comments and 
then formal review.  The current date and time facilities inherited from C 
seem awfully old-fashioned to me, and I'd really like Boost to take a 
serious look at potential replacements.

--Beman