CThinker wrote:Also, clock() isn't required to have any particular resolution. It may be no better than 1 second resolution even if CLOCKS_PER_SEC says something else. It might just multiply the time value by that to give the impression of it being more.
As far as resolution goes, the same can be said for gettimeofday(), which is what I was trying to avoid in favor of clock(). That is, timeval.usec may just always be zero.
True.
If I remember it correctly, most clock() implementations from *nix variants simply make use of gettimeofday().
That I don't know, but that is a good example of unspecified, non-standard libraries.
The C standard tried to specify a lot of useful library routines, but they did screw up in some areas such as time & sorting. And about anything that touches the real hardware or the real world.... But it's still better than no standard at all.
I have yet to see clock() misbehave on me, from stamp-sized HD16 boards with Hitachi C, to IBM C on big AS/400s. So far, I have been very lucky. So, I guess I have to start watching out, from now on.
I bet you did and just didn't notice it.... I bet in at least a few of those cases, it was wall-clock time and in others it was process time.
Often they are so close together you don't notice it. I bet the IBM C got it right, though, and used process time.
You could do ftime().
It's not a standard function, but many platforms support it because Unix had it.
There is still no guarnatee that its resolution is any better than 1 second, but it is faster than many of the Windows specific routines that do provide guarantee higher precision.
Meaning it's something that can be used in your search routine and called hundreds or thousands of times per second without putting too much overhead into the search.
Right off the top of my head, I don't know what most Windows programmers use. I actually try not too look too much at other people's programs. (The only programs I care about are the old programs from the 70's & 80's.)
You could even do a 'fall-back' approach. Write your own wrapper that can call one of several routines depending on the accuracy available on that platform and whether you want wall-clock or process-clock.
When you are testing on your own system, it's often better to do process-clock (that way you can have other stuff running in the background), but in games it's better to have wall-clock. So it can be helpful to program them both in and switch between them depending on a command flag you enter.
