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

Subject: Re: [boost] [timer] Boost Timer Library Version 2
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-09-28 15:21:25

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.

> >> * 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.

> > start() notes the current time as the start time and marks
> > the timer as not stopped, if is_stopped(), and marks the
> > timer as not suspended.
>
> I can't parse that. What does ", if is_stopped()," apply to?
> Or does start() unconditionally mark the timer as not stopped
> and not suspended?

Try it this way:

Effects: If is_stopped(), notes the current time as the start
time.

Postconditions: !is_stopped() and !is_suspended().

> > stop() notes the current time as the end time and marks the
> > timer as stopped, if !is_stopped(), and marks the timer as
> > not suspended.
>
> Same problem with ", if is_stopped(),"  - what does the if
> apply to?

Effects: If !is_stopped(), notes the current time as the end
time.

Postconditions: is_stopped() and !is_suspended()

> > suspend() notes the current time as the suspension time and
> > marks the object as being suspended, if !is_stopped() &&
> > !is_suspended().
>
> Do you mean?
>
>    Effects: If !is_stopped() && !is_suspended(), save the
>    current time as the suspension time and mark the object as
>    being suspended? Otherwise, no effects.

Yes, though I'm purposely using "notes" rather than "saves" to avoid specifying the need to save anything to effect the behavior.

> > resume() calls start() and arranges for a future call to
> > elapsed() to include the time elapsed until suspend() was
> > called plus the time that elapses subsequently, if
> > is_suspended().

Effects: As if start() is called and also arranging for a
following call to elapsed() to include the time elapsed until the
most recent call to suspend() plus the time that elapses
subsequently, if is_suspended().

Postconditions:  !is_stopped() and !is_suspended()

> 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. ;-)

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.