On 11/11/10 09:54, vicente.botet wrote:
From: "John Bytheway" <jbytheway+boost@gmail.com>
On 10/11/10 00:04, vicente.botet wrote: <snip> For example
uint64_t const big = uint64_t(1)<<62; typedef duration<uint64_t, ratio<1, big>> D1; typedef duration<uint64_t, ratio<1, big-1>> D2; D1 d1(0); D2 d2(0); auto d = d1+d2;
Will the above compile? > If so, what is the type of d?
No. there is an overflow. The following compile-time error is obtained:
Good.
What is its intended purpose? It seems to violate the type system somewhat by returning a double rather than an 'inverse duration'.
What would you expect as result?
Unless you returned something from Boost.Units there really isn't a sensible option (and I'm certainly not suggesting you return something from Boost.Units).
You are right. Whithout the correct units the result has no sense. For coherency, I think that I should be forced to remove this overloading, and let Stopwatch make his internal computation.
Thanks; that makes me feel better :).
You seem to be guaranteeing that high_resolution_clock is a typedef of one of the other two clocks? Wouldn't it be better to leave open the possibility that it uses some other, more high-resolution clock?
Yes I could. I don't see nothing in the standard that forbids it. Do you have a better implementation for high-resolution_clock and for which platform? I could include it if you have one.
For Windows there's QueryPerformanceCounter and QueryPerformanceFrequency that people are always suggesting for use in Boost.Timer.
Boost.chrono uses already them. I will add the following table as requested. <snip>
Cool. For POSIX process/thread times, I note the existence of clock_gettime(CLOCK_PROCESS_CPUTIME_ID) and clock_gettime(CLOCK_THREAD_CPUTIME_ID) which are possibly candidates for the process / thread timings. At the same time, their man page says they're unreliable on SMP systems, so probably not useful.
I believe there are similar things on other platforms. One thing I would like is a common interface akin to libfftw's getticks. (See the "Cycle Counters" part of http://www.fftw.org/download.html). This is also in arbitrary units, not seconds, though, and I'm not sure how many of the underlying APIs have a known compile-time precision.
Without the processor speed the getticks() function is not of utility for the Chrono framework. If the user know the processor speed in Mhz at compile-time s/he can define a cycle_count_clock in a simple way as follows:
Right; I see that. My point was that the implementation of getticks itself has lots of platform-specific code in it, and something equivalent might be usefully added to Boost (but probably not in Boost.Chrono).
There is Boost.Stopwatch which will be reviewed 1Q/2Q 2011 that should cover the needs. Please take a look at and let me know if you fid there what you are looking for.
I tried, but the documentation link on LibrariesUnderConstruction doesn't seem to work (I get a blank page).
I don't get blank page. Please could you try http://svn.boost.org/svn/boost/sandbox/chrono/libs/stopwatches/doc/html/inde...
Yes, that works. Thanks. John