Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW

Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-11-15 18:22:18

On 15/11/10 22:53, vicente.botet wrote:
>>> 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).
> 
> I was thinking about this and if we had a cycle_count_clock class it
> would be easier for the user to express the time in ticks, so no
> transformation will be necessary when operating on them. Do you see
> any problems to a ticks duration class, that would be able to be
> converteed as the other durations?

It sounds reasonable, but a better understanding than mine of the
implementation details of getticks would be required to know for sure.
In particular, the one in libfftw has no provision for conversion to
'real' time units like seconds, and at present I have no reason to
believe that this is possible in general; I don't know how varied the
functions used are.

John