Support MinGW

[Alpar Juttner]

Support MinGW

[Balazs Dezso]

I uploaded a port for time_measure.h
It is modified in order to support mingw32 time functions.

[Alpar Juttner]

A port of time_measure.h can already be found in ticket:52. Therefore I suggest waiting with this until those changes gets into the main branch.

[Balazs Dezso]

New patch based on the ported time_measure.h.

[Alpar Juttner]

Replying to deba:

New patch based on the ported time_measure.h.

Thanks. In fact, it seems to be more than just a mingw compatibility fix, a lot of internals has also (positively) changed.

I have to minor issued.

1. In the old version, TimeStamp stored the number of kernel ticks instead of seconds because I was worried whether rounding error could cause some problem. (The time of a kernel tick cannot be represented precisely on a double). Right now, I cannot see any real-life example where it would really cause problem, so I'm not against this change at all, just ask you to reconsider this change once more.
2. In the stamp() function, please move the #ifdef into the execution block. (Otherwise it may happen that the documentation will not be generated to this function on Windows.)

[Balazs Dezso]

Replying to alpar:

Replying to deba:

New patch based on the ported time_measure.h.

Thanks. In fact, it seems to be more than just a mingw compatibility fix, a lot of internals has also (positively) changed.

I have to minor issued.

1. In the old version, TimeStamp stored the number of kernel ticks instead of seconds because I was worried whether rounding error could cause some problem. (The time of a kernel tick cannot be represented precisely on a double). Right now, I cannot see any real-life example where it would really cause problem, so I'm not against this change at all, just ask you to reconsider this change once more.
2. In the stamp() function, please move the #ifdef into the execution block. (Otherwise it may happen that the documentation will not be generated to this function on Windows.)

[Balazs Dezso]

2) I uploaded the new patch based on your issue. 1) In my opinion, the rounding error is just a slightly dependent on this change. If t1 and t2 values are the retrieved timestamps and c is the clock time, then the (t2-t1)/c and the t2/c-t1/c should give back nearly the same value, because the division could not cause big relative error. But I think, the conversion from clock_t to double, which is already in the original version, could cause big relative error, when we subtract t1 from t2. However, on a regular linux desktop it does not cause problem, because the sensitivity of timer is at most 1/1000 second, and the double value has 52 binary digits, so more than 140 thousand years can measured with TimeStamp??.