On Fri, 23 Apr 2004 19:50:47 -0400, Beman Dawes wrote
At 08:37 AM 4/21/2004, Toon Knapen wrote:
The documentation of boost::timer states that 'The maximum measurable elapsed time may be as low as 596.5 hours (or even less) ...'.
Well on many 32bit platforms this would probably even be about 71 hours. Apparantly POSIX requires CLOCKS_PER_SEC to be 10e6, so if clock_t is 32 >bit, the maximum of ( clock() / CLOCKS_PER_SEC ) is 4294 seconds.
Because accuracy for clock() is generally about 1 sec,
As Jeremy Maitin-Shepard commented, clock() is usually better than that. .001 seconds at least. But see comment below.
using clock() is not very usefull for doing timings of short (in time) events. Even more, >for short events, the boost::timer might also influence the timing too >much. So clock() is generally interesting for longer timings (from 10 >sec onwards). > >But for long events the clock_t wraps around too fast (as mentioned >above). And if you're unlucky that you _start_time = clock() is or a bit >smaller than std::numeric_limits< clock_t >::max() (thus near the >wrap-around point), directly afterwards the expression 'clock() - start' >will result in a negative value. > >So I would like to suggest for boost::timer to use std::time_t and use >std::time(NULL) instead of clock() and use std::difftime to calculate >the elapsed time.
boost::timer dates from the earliest days of Boost, when we were limiting ourselves to implementations which used only the C++ standard library.
boost::timer should really be redone (and then be reviewed) using current Boost practice. Key changes:
* It should either become a part of the date-time library or at least be made compatible with date-time. As a practical matter, that means close coordination with Jeff Garland.
* Behavior should be specified, and then implementations done for various platforms which meet that behavior. Specifying behavior such that all platforms will behave in the same way, yet the behavior is sufficiently useful, is non-trivial. The precision and latency of native timing API's can change from release to release, so it is important not to over-specify the behavior.
If anyone would like to volunteer to take that on as a project, it would be appreciated.
I'd be happy to take on the task of moving the timer into date_time. I've been planning on doing this for awhile, but it just hasn't been a high priority. I'll try and dig up all the prior discussion on this topic and put together an interface proposal. I don't see why we can't try and target something for the next release assuming we can do a collaborative development and/or fasttrack review. BTW, I believe the interfaces for the timer should be templatized to support various 'clock devices' that can support different timing resolutions and properties. For example, if I happen to have an gps derived clock laying around it would be nice to write a little adaptor and use it for a high precision timer. This can also help with portability since different platforms can support different resolutions if need be. That way the interface doesn't have to be over-specified, but rather becomes platform driven. I've started gathering material for this on the Wiki. Others, please contribute requirements and issues. I'll post more when I think there is something substantial to review. Jeff