|
Boost : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2007-02-25 14:07:31
David Abrahams wrote:
> Jeff Garland <jeff_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> 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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk