Andy Haas wrote:
>
> I believe there's a bug in TStopwatch of the new release (2.00/11). At
> least, they don't act like they used to and are documented to act.
>
> The following macro demonstrates:
>
> {
>
> w = new TStopwatch();
> for (int i = 0; i<10000000;i++) { }
> w->Stop();
> w->Print();
>
> w->Start();
> for (int i = 0; i<10000000;i++) { }
> w->Stop();
> w->Print();
>
> w->Start();
> for (int i = 0; i<10000000;i++) { }
> w->Stop();
> w->Print();
>
> w->Start();
> for (int i = 0; i<10000000;i++) { }
> w->Stop();
> w->Print();
>
> }
>
> The results are:
>
> root [2] .x haas/bench.c
> test : Real Time = 2.04 seconds Cpu Time = 2.04 seconds
> test : Real Time = 4.09 seconds Cpu Time = 4.09 seconds
> test : Real Time = 6.13 seconds Cpu Time = 6.13 seconds
> test : Real Time = 8.16 seconds Cpu Time = 8.16 seconds
>
> I believe that they used to reset after each "stop". Now they seem to
> continue where they left off. TBenchmark exibits the same behavior now
> (of course). I believe the fState variable is not functioning
> correctly. It used to be a static set of variables and is now an
> enumeration, which should work, but apparently doesn't.
>
This class was recently modified by Valery Fine (sorry not mentioned
in the release notes).
Thanks Andy for reporting the problem.
Please Valery check your "improvement"
Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:37 MET