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: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-15 17:53:38

----- Original Message ----- 
From: "John Bytheway" <jbytheway+boost_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, November 11, 2010 8:40 PM
Subject: Re: [boost] [Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW

>>> 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).

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?

Best,
Vicente