Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-11-11 14:40:58
On 11/11/10 09:54, vicente.botet wrote:
> From: "John Bytheway" <jbytheway+boost_at_[hidden]>
>> On 10/11/10 00:04, vicente.botet wrote:
>> 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
>>>> What is its intended purpose? It seems to violate the type
>>>> system somewhat by returning a double rather than an 'inverse
>>> 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
For POSIX process/thread times, I note the existence of
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
>>> 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
Yes, that works. Thanks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk