Re: [boost] [Chrono] Proposed library now feature complete

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
>> }
>>
>> 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