Beman Dawes wrote:
The Chrono library in the sandbox is now more-or-less feature complete. In addition to the C++0x features, timers have been added to replace the old Boost.Timer library which will become deprecated.
The feature list includes:
* The C++0x Standard Library's time utilities, including: o Class template duration o Class template time_point o Clocks: + |system_clock| + |monotonic_clock| + |high_resolution_clock| * Class template |timer|, with typedefs: o |system_timer| o |monotonic_timer| o |high_resolution_timer| * Process clocks and timers: o |process_clock|, capturing real, user-CPU, and system-CPU times. o |process_timer|, capturing elapsed real, user-CPU, and system-CPU times. o |run_timer|, convenient reporting of |process_timer| results. * The C++0x Standard Library's compile-time rational arithmetic.
See http://svn.boost.org/svn/boost/sandbox/chrono
The implementation is now working and lightly tested on Windows with VC++ 9.0 SP1 and Intel ia32 11.0 compilers, and on Ubuntu Linux with GCC 4.2.4 compiler.
There is a bit more documentation, but it is still needs much work.
Comments are welcome.
Shouldn't the implementation use boost::throw_exception rather than throw? In the past I've seen QueryPerformanceCounter give incorrect results, especially with SpeedStep processors on laptops. This was many years ago and might have been fixed by service packs and drivers. Typically you check the results of QPC against GetTickCount to see if the results are reasonable. http://support.microsoft.com/kb/274323 I've also heard of problems with QueryPerformanceCounter in multi-processor systems. I know some people SetThreadAffinityMask to 1 for the current thread call their QueryPerformance* functions then restore SetThreadAffinityMask. This seems horrible to me because it forces your program to jump to another physical processor if it isn't already on cpu0 but they claim it worked well in practice because they called the timing functions infrequently. In the past I have chosen to use timeGetTime with timeBeginPeriod(1) for high resolution timers to avoid these issues. -- Michael Marcin