you have no way of knowing what time elapsed since previous call, so you can handle possible error.

yeah function has the same flaw, only it takes little longer, and its vista+ what disqualify it from general programming.

a115433,

Aha, 2³² times longer (Good catch! Universe probably collapse significantly before the overflow. ). What are you proposing, infinite precision tick counter?

Pretend to be an astronomer and use Julian dates.

Little? WTF, little???

Well, no one felt tempted to answer your previous questions so here they go:

>And you think this 50 days is really 50 days?
No, it is ~49.71 days.

>What if i change frequency of power supply, so realtime clock will go faster?
Power supply frequency? Is this CPU frequency maybe? The real-time clock has little to do with this AFAIK, here it is used the PIT/APIC timer (or whatever is used in modern PCs) to keep the counting. Probably some error still exists but I would be very surprised if it is too gross.

>What if i do something with clock itself?
GetTickCount spec would be violated, it has to count milliseconds, not whatever a naughty driver decided by changing the hardware timer without notifying the kernel. The same applies to processors supporting a fixed rate TSC, some driver could reset the counter making the illusion that hundreds years passed in a matter of nanoseconds.

>What if i manage to get on top secret military server, hang the application between GetTickCount() exactly -1 microseconds, so both calls return same value? And the next code will behave diffrently after it? For example divide by 0 (maybe in module responsible for logging statistics)?
No one will notice in 50 days that? Then I'm very thankful of the "design error", those guys really deserve the crash for those tons of incompetence.

LocoDelAssembly,

What if god wakes from the eternal sleep and ~universe before the second call to GetTickCount()? That will ruin the entire algorithm!

"They've killed Kenny!" — "You bastards!"

Yeah! We need GetTickCount4294967296(). I won't settle for anything less.

revolution,

About to have "that doesn't compute" error. Quantum states of all particles in the universe don't seem to hold such a counter. Yet there is a probability that I don't count them properly.

Limits are as such, limits. When you don't care about them, they're striking back.

It only takes 512MB to store a 4Gb number.

revolution,

Damn, I thought about 2↑↑32. That happens.

Can we assume "↑" means this?

If so, then that is an awfully big number! We could count sub-yocto-yocto-yocto-yocto-Planck times and still not run out of bits to count with for the foreseeable future.

It's awfully small. There were already MUCH bigger numbers.

getdatetimetick()

maybe it can be better.

with the format like this:
YYYY/MM/DD ; hh:mm:ss:tick
16bits/4bits/5bits ; 5bits/6bits/6bits/10bits
then, without any problem, i can say only 52bits are largelly enough to gettickcount until the year 65536.
assuming tick resolution is 1millisecond and year starting at jesus birth.

when getting time, don't forget to get the date, to see if there are overflows.

thats what i name good coding.

revolution,

Yes, that's D. E. Knuth arrow. I thought of it first because such counter will probably satisfy a115433's needs.

__________
Fanael,

Is Graham's number big enough?

__________
edfed,

B.C. dates should be available too. What about year 0?

Years 32,768 and 65,536

lol, we can troll about that a very long time, at least 30757 more years

Anyone dares to test my BUG.EXE ?? Preferably on Vista running for > 50 days without reboot Post shot

Nope. It's of course big, but it is very small compared to other answers.

lol, win98 cannot gives years over 2099 and under 1985.
i cannot creates files at my day of born.
and if i live that long, i hope i'll have my own OS.

what i like on this board is that we don't stop to feed the trolls, we feed him so much that he becomes ill and fed up. mouarffff

nonononono
resolution is not important!
make 100 functions GetTickCount(), GetTickCount2(), GetTickCount4(), etc...

But let each of them return error in case of overflow!


GetTickCount() has the resolution of unsigned 32 bits, that is:
4294967295 miliseconds
wich is 4294967 (+ .295) seconds
its 1193 (+ .0464708(3)) hours. since x86 allow only 32 bits, (3) is rounded down to 3.
1193 (+ .04647083) hours
and it is 49.71026961791(6). since (6) cant fit into limited register, round up to 7, and we have maximum abbount of days that can pass between 2 effective (actual read from counter) calls of GetTickCount() = 49.710269617917 days. And thats assuming in calculations we used modulo from DX.