Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-04-23 18:50:47

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


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