Re: [boost] [timer] Boost Timer Library Version 2

Subject: Re: [boost] [timer] Boost Timer Library Version 2
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-30 15:32:52

Le 28/09/11 21:21, Stewart, Robert a écrit :
> Beman Dawes wrote:
>> On Wed, Sep 28, 2011 at 8:38 AM, Stewart, Robert
>> <Robert.Stewart_at_[hidden]>  wrote:
>>> Vicente J. Botet Escriba wrote:
>>>> * Why does stop returns cpu-times? Why by reference? Why
>>>> elapsed is not returned by reference?
>>>>
>>>> cpu_times         elapsed() const noexcept;
>>>>
>>>> const cpu_times&    stop() noexcept;
>>> The interface is, of course, directed by the current
>>> implementation.  Still, it would be appropriate for stop()
>>> to return by value to avoid forcing the implementation to
>>> store a cpu_times instance in the timer.
>> There is only one set of times in the timer. How could an
>> implementation not store the start times within the timer?
> It needn't be stored as a cpu_times object, but see the end of this post.
Boost.Stopwatch stores a time_point  representing the last start or 
resume and a duration that cumulates the segments of a lap. A segment be 
defined by start->stop, start->suspend, resume->suspend and resume->stop.
>
>>>> * I would associate the operations pairwise start/stop and
>>>> suspend/resume. I guess it would be easier to explain the
>>>> semantics.
>>> Here's the new interface:
>>>
>>>    void      start();
>>>    void      stop();
>>>    bool      is_stopped();
>>>    void      suspend();
>>>    void      resume();
>>>    bool      is_suspended();
>>>    cpu_times elapsed();
>> I'm totally confused by having four states: stopped/suspended,
>> stopped/not-suspended, not-stopped/suspended,
>> not-stopped/not-suspended.
> stopped/suspended is an invalid state.  suspend() only suspends if !is_stopped().
>
> stopped/not suspended means stop() was called.  The only valid transition is to call start().  Neither suspend() nor resume() does anything if is_stopped().
>
> not stopped/suspended means suspend() was called.  The timer is running, but suspended.  There are two valid transitions: stop() or resume().
>
> not stopped/not suspended means start() was called and neither stop() nor suspend() was called.
I agree. The implementation can store whatever needs to represents these 
states. It is not forced to have two boolean fields stopped and suspended.
>
<snip>
>> How is your example different from this?
>>
>> nanosecond_type status_time(0);
>> cpu_timer timer;
>> for (int i(0); i<  100; ++i)
>> {
>>      task_to_time();
>>      scoped_stop_and_resume(timer);
>                              ^- some identifier
>>      nanosecond_type const current_time(timer.elapsed().user);
>>      if (1000000000<  current_time - status_time)
>>      {
>>         report(timer);
>>         status_time = current_time;
>>      }
>>      timer.resume();
>        ^^^^^^^^^^^^^^^
> Not needed, given your scoped_stop_and_resume object.
>
>> }
>>
>> How is that different from stop() and resume() with current
>> interface?
> Um, well, hmmm.  It isn't.  I guess I got the idea in my head that resume() provides lap counter behavior such that the final elapsed time would include the time spent calling report(timer), etc.
>
> start() and stop() have easy semantics as do suspend() and resume().  All four together are not, perhaps, quite as nice, given that resume() *doesn't* have lap counter behavior.
>
> It's still reasonable that stop() not return a value.  Then start()/stop()/resume() is complete and consistent.  I just have to quit thinking wrongly about resume()!
>
> "scoped_suspend" is nicer than "scoped_stop_and_resume", though. ;-)
>
Hi,

in Boost.Stopwatch a lap is considered by the time between a start and a 
stop, possibly suspended/resumed several times.

Laps can be stored in some kind of *memory*. The simple memory is a 
one-shot memory that gives you just the information about the current 
lap (or the last lap if the stopwatch is stopped. We can use also an 
accumulator set to memorize some statistics of several laps or just 
store the lap samples in a container for later processing.

For this reason Boost.Stopwatch don't use stop and resume as you are 
proposing.

I don't know if I have already said this in another post, 
Boost.Stopwatch provides scoped runners, stoppers, suspenders and 
resumers. The idea is that a scoped_operation realize the operation on 
the constructor and the pairwise on the destructor. Scoped runners are 
there to identify the context of a lap, scoped stoppers allow to 
identify the complementary of a lap.

Best,
Vicente