Le 17/11/11 20:28, Kenneth Porter a écrit :

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch).

Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

Boost.Chrono provided different clocks, but no date. Maybe this is was you are locking for :) Best, Vicente

On 11/17/2011 1:28 PM, Kenneth Porter wrote:

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch).

Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

My guess is that the tricky part lies in the fact that QueryPerformanceCounter returns a rather arbitrary number. You may convert a difference between two such numbers to a real time duration but it does not seem to be trivial to convert one number to a real time point. I think this is the reason GetSystemTimeAsFileTime fits date_time design better than the QueryPerformanceCounter. Ilya Bobyr