Sign in to follow this  
Cornstalks

std::clock() and its Limits?

Recommended Posts

Now I doubt I'll ever have a problem with this, but I assume there are some programs one could create which would run into this problem. std::clock() returns the running time of the program (though its start time may not be exact across all platforms). It typically runs at 1000 ticks per second. Here's the problem: if std::clock() returns some data type represented as an unsigned 32-bit integer, what if the program runs for 50 days straight? This would require std::clock() to return 4320000000, which is above the limits of an unsigned 32-bit integer. If a program bases a function on the std::clock() function, are there any precautions that should be taken for that program or any potential problems? Before you start freaking out asking why I need a program to run for 50 days that relies on the clock() function, realize that I don't. This is just hypothetical, and it would help me know what to do just in case I ever came into a situation where this would be a problem. Thanks!

Share this post


Link to post
Share on other sites
why not use SYSTEMTIME?

SYSTEMTIME start;
SYSTEMTIME current;

void initRuntime ()
{
GetLocalTime (&start);
}

// __int64 is only available on MS compilers
__int64 getRuntime ()
{
GetLocalTime (&current);

// calculate delta days, minutes etc between start and current
__int64 rt = 0;
rt = delta.wMilliSeconds + delta.wSeconds*1000 + delta.wMinutes*60000//etc etc
return rt;
}

Share this post


Link to post
Share on other sites
Quote:
Original post by thre3dee
why not use SYSTEMTIME?
Because it's non portable?

If you're guaranteed to be polling regularly (well.. once every 50 days anyway) then something like this ought to work:
uint64_t poll(void) {
static uint64_t whole = 0;
clock_t frac;

frac = clock();
whole += (unsigned clock_t) (frac - (unsigned clock_t) whole);

return whole;
}


[Edited by - implicit on May 8, 2008 2:09:11 AM]

Share this post


Link to post
Share on other sites
Well, you could either use uint64_t or just a second unsigned int to count the number of times it's rolled over.

Either way, it's going to last a little over half a billion years before it hits the limit at 1000 ticks per second.

Share this post


Link to post
Share on other sites
Quote:
Original post by tychon
Well, you could either use uint64_t or just a second unsigned int to count the number of times it's rolled over.

Either way, it's going to last a little over half a billion years before it hits the limit at 1000 ticks per second.


This simple extra counter should suffice! Essentially you'd be making your own 64-bit 2-part integer without the need for 64-bit integer support.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this