On Sun, 16 Jul 2006 23:09:29 +0200, "Philippe Vaucher" <philippe.vaucher@gmail.com> wrote:
What I don't understand is why you didn't talk earlier in this thread ? You seem to have missed a lot of discussion where your input would have been interesting.
I haven't followed this thread closely. But precisely where I should have spoken?
* 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()
It's basically the same design than Jeff proposed (about it being templated on the clock) except it's not tied to the boost::date_time interface
I don't know. What I noticed in your code is that you have to call clock_type::local_time() in some places. And I didn't think this was the case when seeing the interface specification. That's certainly due to my ignorance on boost::date_time; but, admittedly, you don't need any time point from a logical point of view (or you can go with an irrelevant "instant zero" time point reference which doesn't affect results).
which makes it suitable for timers like QueryPerformanceCounter, that's why I think I'll refactor it a bit to follow your design so we can have one generic template class instead of template specializations.
BTW, those were partial template specializations, which rule out VC6 and other compilers.
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.
Right so you are actually proposing whole new round of discussions... ok, I thought we had this behind :) I'm not used to the boost mailing list enough I guess.
Sorry, but, if that may comfort you, it's a good thing. The more it will be at the drawing board, the less in the debugger and in the feature request list ;) PS: I'm also experimenting a bit in assembly with time stamp counters; I've tried them on an Intel P4 and the results are impressive. The way to insert assembly code vary with the compiler but that can be easily be managed. Probably other CPU brands could be supported. For now I haven't considered AMDs (the Intel documentation is quite long already :) But it's a joy to read) and SMP systems. Furthermore, cache misses during frequency measurements are taken into account, but dynamic frequency adjustments, such as performed via SpeedStep, are not. But it's just a first cut. And then, I don't think one would want to use these facilities with SpeedStep in the way. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]