Subject: Re: [boost] [Chrono] Proposed library now feature complete
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2008-11-19 10:12:16
On Nov 19, 2008, at 6:29 AM, Beman Dawes wrote:
>> That being said, I just reviewed several POSIX time functions and
>> it really
>> looks like they just don't fail. I know the ones on darwin don't.
> The POSIX clock_gettime function can fail with [EINVAL] "The clock_id
> argument does not specify a known clock."
> The Windows QueryPerformanceCounter/QueryPerformanceFrequency
> functions can fail "if the installed hardware does not support a
> high-resolution performance counter".
Ok, I had overlooked these run time failure modes. So the ec&
overload looks much more appealing to me now.
>> * I've written utilities like this in the past. I've always put the
>> functionality of elapsed() plus a print statement in ~timer() so
>> that use
>> cases looked like:
>> int main()
>> timer _("Entire Program");
>> // do stuff
>> Elapsed time for Entire Program was 15 seconds.
> Sure. The name of the type is "run_timer" and it is declared in header
I had overlooked run_timer (I didn't do a proper review). <nod> this
looks quite nice. Very nice formatting capability and streaming
> Howard, I'm pressed for time so only skim read the remainder. My quick
> impression was that my proposed decomposition into clocks (some
> provided by the std lib, some by Boost or users), raw timers, and then
> elaborated timers derived from raw timers provides all the
> functionality you mention in a easy to use package, yet allows users
> to avoid functionality they don't need for a particular application.
Agreed. The only functionality I'm not sure I see is the ability to
get the total time in a function across multiple calls:
static run_timer t("Total time spent in f1 was %r seconds."); //
sum times over many calls to f1()
t.start(); // first start is redundant and ignored
t.stop(); // I don't see this functionality
The stop() functionality would add more complexity/data members to
run_timer (like a "running duration" which sums previous start/stop
sequences, and a count of start/stop sequences so an average can be
reported), so might conceivably be another class derived from
run_timer, possibly written by the client instead of by boost. Not
sure, I haven't tried that route. And it may be that there isn't a
sufficiently large market for this functionality for the boost lib to
worry about. I'm just relating my experience.
Nice work Beman. I know what you have will be greatly appreciated by
the boost community.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk