On Sun, 16 Jul 2006 16:41:41 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> 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 ]