Re: [boost] Low-level precision timer proposal - Part II

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-07-16 15:04:53

On Sun, 16 Jul 2006 16:41:41 +0200, "Philippe Vaucher"
<philippe.vaucher_at_[hidden]> wrote:

>>
>> They also are in the vault now, in Home/System
>
>
>Hum there's something I need to understand, what you uploaded is what needs
>to be merged with the code I did ?

Er, no. I didn't use the word "merge" in that sense. It was meant as
"we can combine the best of the two approaches" in a new design.

I started working on the timers after noticing some flaws in the
current boost::timer, particularly the fact that it doesn't take into
account that std::clock() can fail. In the first draft of my code no
boost::date_time facility was used, partly because I wanted to come up
with an autonomous solution and partly because I'm a billy goat with
the date-time library in general (I wanted my code to be interoperable
with date-time, but not depending on it; just like you can often make
a template mpl-compatible by just providing a nested "type" typedef).

Well, so far with history :) The main idea in my code is that "elapsed
timers" are all about *durations*, and do not need to involve *time
points*. A duration is not affected by what your system time is,
whether you switched to DST or things like that. That's a key point.
The code I provided added the interface that Jeff Garland proposes on
the wiki page to the code I had already written (secondary point:
there are some comments about the interface itself in the code).
Basically:

* it separates the "elapsed timer" notion from the notion of "clock
device" (the "source"); the advantage is that you can plug-in any
source you want. The only requirement on the source class is that it
provides:

  - a time_duration_type typedef
  - void start();
  - time_duration_type elapsed()

As you see, just a typedef and two functions. Note that the source
doesn't need to know about "pauses" and "resumes"; I find that very
close to the actual logic of any involved physical devices: you don't
want to really pause, say, a NTP server, even if you could. Pauses,
etc., are handled by the elapsed timer template class, which offers
Jeff's interface.

Other two ideas which are IMHO worth considering are:

* [std::clock() specific ] when you first invoke std::clock() you
could actually be between two ticks. Since the time between two
consecutive ticks can be as long as one second or more, that's not
negligible, and here's the point of the synchronized start: it waits
until the clock really ticks. Secondly, elapsed_min() is actually what
c_clock_precision() computes, at run-time, and cannot be inferred from
CLOCKS_PER_SEC, which is a mere conversion factor (posix requires it
to be fixed at 1,000,000 but that doesn't mean you can measure
millionth of seconds)

* use of exceptions: clock device classes, and thus elapsed_timer<T>
can provide strong exception guarantees; and, yes, std::clock(),
GetProcessTimes, etc. can all actually fail in practice.
  
That should cover the basics and make the code comments more
understandable. In short, we are still at the drawing board, but once
the design is in place, it really takes a little time to write down
the code.

--
[ Gennaro Prota, C++ developer for hire ]
[    resume:  available on request      ]