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 }
Output:
Elapsed time for Entire Program was 15 seconds.
Sure. The name of the type is "run_timer" and it is declared in header <boost/chrono/process_times.hpp>
I had overlooked run_timer (I didn't do a proper review). <nod> this looks quite nice. Very nice formatting capability and streaming options.
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: void f1() { 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. -Howard