Ok, this doesn't really pertain to what I'm actually doing right now, but I am curious what actually goes down. I've tried to find the answer, but it seems this question isn't asked too often XD

I am currently implementing a motion module in my game which basically computes "timed-movements" (simply put, makes sure that objects move consistently with time), and while I was looking for a class that queries a performance counter, I came down to something that I have not thought about before.

The performance counter basically just keeps count of how many milli/nanoseconds have passed since the system started, but the count is stored in a variable of type long (at least the one I'm using). Now obviously a long is a very large variable and chances are it won't run out quickly, but if someone is running a server day and night, the variable will run out of range eventually (unless it's 64 bit I quess... at a range -/+9 quintillion, it could run for years on end).

I imagine that if the variable runs out, it will simply wrap around and start back at -x right? Does this mean that programs with possibility of overflow need to introduce a solution that will take into account that kind of behaviour? Or is there something else happening that I'm not aware of?

I read somewhere once that it is quite possible for CoCreateGUID to return the same value on two different systems, but it is actually far more likely for life on the planet to be wiped out by an asteroid strike, so it isn't really worth worrying about.

This is probably a similar sort of thing, but it is something I'd wondered about in the past so interesting topic.

There isn't actually a problem if you use it correctly. What you do is treat the values as unsigned and them subtract them. The result will not only never be negative (obviously as you're subtracting unsigned types) but the answer is also correct exactly as if the values were in the middle of the range, thanks to how unsigned arithmetic works.

This more often applies to GetTickCount, which IIRC can only run for something like a month before it rolls over. Provided you subtract using unsigned, and don't have times greater apart than the maximum value it can hold, then it works just fine.

There isn't actually a problem if you use it correctly. What you do is treat the values as unsigned and them subtract them. The result will not only never be negative (obviously as you're subtracting unsigned types) but the answer is also correct exactly as if the values were in the middle of the range, thanks to how unsigned arithmetic works.

This more often applies to GetTickCount, which IIRC can only run for something like a month before it rolls over. Provided you subtract using unsigned, and don't have times greater apart than the maximum value it can hold, then it works just fine.

The problem isn't of the counter turning negative, but rather smaller than the current count. Even if the unsigned did not turn negative, it would wrap around to 0. I understand what you mean that the variable will be too big to ever run out anyway, but that's not what I meant to ask XD I just wanted to know if I was right to assume that this would happen.