Dear Mr. Dawes: First of all, I would like to thank you for the small, but very convenient class. I used it for timing my CPU-intensive codes. However, while using it on Windows machines, I encountered a problem not reflected in documentation: == Summary: == Boost Timer measures a conceptually different timing under Windows than under other operation systems. It is proposed to describe the difference in documentation. For modern versions of Windows the problem can be fixed easily, but with Windows 95/98/ME it is not so. == Description == Under most of operation systems, Boost Timer measures the CPU time consumed by a program. The timing does not include CPU cycles used by other programs running on the same computer, nor the time when the program is waiting for I/O. Under Windows, Boost Timer measures instead the whole wall-clock time elapsed. If other resource-hogging programs like Norton Antivirus, Norton Speed Disk defragmentor, or Skype are running simultaneously with a timed program, the timer will reflect it. If you are timing five copies of the same CPU-bound program, Boost Timer reports that the program became five times slower. If the timed program is waiting for an user input, the timer reports how long coffee break the user took. All of this makes Boost Timer, well, not very suitable for timing of CPU bound codes running under Windows. Even for a rough timing. == The reason == The underlying problem is in std::clock(). Under Windows, the function does not measure the amount of CPU time used by a process. It measures instead the "wall clock" time elapsed since the program started: http://msdn2.microsoft.com/en-us/library/4e2ess30(VS.80).aspx see also discussion here: http://www.cygwin.com/ml/cygwin/2004-07/msg00164.html http://www.cygwin.com/ml/cygwin/2004-07/msg00175.html The Microsoft documentation shows that it is true for all current and recent desktop versions of Windows, starting from year 1995. To my recollection, it was true for MS DOS as well. Hardly an ANSI behavior, but it is so. == Possible solutions == 1. Taking in account how many computers are running Windows, I would suggest to describe the difference in Boost Timer documentation. Currently the documentation discusses a relatively minor problem with low resolution of Boost Timer under Windows, but does not mention the much bigger issue. 2. It is more debatable is if it makes sense to fix the class. 2.1. Boost Timer was around for so many years already, that it probably makes sense to retain its old behavior for compatibility - like Microsoft did with clock() for compatibility with DOS. Personally, I would implement the fixes as a separate class cpu_timer. 2.2. As it was discussed in the Rationale section of documentation, different versions of Windows would require different fixes: On all modern desktop and server versions of MS Windows, starting from NT ver. 3.51 and including all versions of Windows 2000, Windows XP, Windows Server 2003, and Windows Vista the right behavior can be implemented using function GetThreadTimes described in Microsoft documentation: http://msdn2.microsoft.com/en-us/library/ms683237.aspx Windows CE, strating from versions 3.0 or even 2.12, also supports this function, but vendors can remove it from vendor-specific builds: http://msdn2.microsoft.com/en-us/library/ms908464.aspx For Intel Pentium 4 processors running in hyper-threading mode the solution will give distorted result, but it is probably unavoidable. See an useful discussion on the Microsoft forum: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=990282&SiteID=1 The solution is completely incompatible with Windows 95 / 98 / ME, because the OS do not support the GetThreadTimes function. Is there is still a need to support these quaint versions of Windows in the year 2007? == Additional question == You mentioned in the documentation a rejected Win32 implementation submitted by John Maddock. Where can I find it? I would like to compare it to my timing codes for Windows. Sincerely, Yura