David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
testing.capture-output date_time/testmicrosec_time_clock.run
looks like a Boost bug.
2007-Feb-25 10:27:54 2007-Feb-25 10:27:54.730125000 Pass :: hours match Pass :: minutes match Pass :: seconds match Pass :: hours date Pass :: last is less 2007-Feb-25 10:27:54 2007-Feb-25 10:27:54.730125000 Pass :: hours match Pass :: minutes match Pass :: seconds match Pass :: hours date FAIL :: last is less ... It's not a bug in the library -- your machine is too fast. The test is, as much as anything, a test that the clock on the machine
David Abrahams wrote: provides monotonically increasing values. So there's 3 possible solutions. 1) Change the test to use >= in the time comparisons,
So you're telling me there's a bug in the test. That's still "a Boost bug."
It's a feature, not a bug ;-) I wrote the test this way intentionally so that I could see what happens on various platforms. For example, if the clock, *never* increments that's just as much a problem as the clock returning a less value when it should always increase. But at this point with boost running on tons of platforms and the clock code working on all of them it's just causing problems and not telling us anything useful.
2) increase the number of loops between measurements, or 3) ignore it.
4) Keep looping and measuring until the value changes or a timeout expires?
Nah...I'll just make it >=. Jeff