Immer wieder sehe ich Code um GetTickCount oder Aussagen, die sich um den Überlauf von GetTickCount drehen, der alle 49,7 Tage entsteht. Muss man also irgendwelche Vorkehrungen treffen, wenn man Zeitdifferenzen errechnen will?
Eigentlich muss man sich gar nicht darum kümmern, sofern man in 49,7 Tagen eben mindestens einmal diese Differenz errechnet und das damit dafür gesorgt ist, dass diese Differenz nicht größer sein kann als eben besagt 49,7 Tage.
DWORD dwStart=::GetTickCount();
while (::GetTickCount()-dwStart < dwTimeout)
DoSomething();
Die Arithmetik über unsigned Integer macht es an dieser Stelle möglich. Dieser Code funktioniert, solange eben DoSomething nicht länger als 49,7 Tage dauert. Das ist die einzige Bedingung!
Leider schweigt sich die normale Windows SDK Doku zu GetTickCount darüber aus.
http://msdn2.microsoft.com/en-us/library/ms724408.aspx
Eigentlich problematisch an dieser Stelle, ist es nicht Differenzen zu bilden sondern Vergleiche durchzuführen ❗
Einen interessanten Zusatz dazu findet sich jedoch in der Windows CE Doku. Warum dieser Zusatz nicht auch in der normalen SDK Doku steht ist eigentümlich. Im Allgemeinen empfinde ich die CE-Doku in der MSDN immer eher als lästig.
Es ist aber eben wahrscheinlicher, dass dein CE Rechner und dementsprechend Programme die darauf laufen, länger als 49,7 Tage laufen als auf einem Desktop, ohne einen Reboot, alleine schon wegen der Security Updates, so kann man sich diesen Umstand zumindest erklären.
http://msdn2.microsoft.com/en-us/library/ms885645.aspx
When using GetTickCount, subtraction is safe but comparisons such as
if (GetTickCount() > MyTickCount)
are not. You can use the GetTickCount function to time the duration of an activity as shown in the example below, but using GetTickCount for any other operation will cause issues.
wOldTime = GetTickCount();
DoSomething();
dwTimeElapsed = GetTickCount() – dwOldTime;
Gleiches findet sich in der Windows Mobile 6 Doku noch etwas besser
http://msdn2.microsoft.com/en-us/library/aa915056.aspx
When using GetTickCount, subtraction is safe, even if the rollover occurred, and subtraction always yields the correct difference and the number of clock ticks passed between two tick values. Comparing tick values directly does not always yield the correct results; only compare the differences. Be sure that your code can service the difference before the second rollover, that is, before another 49.7 days pass. Comparisons such as the following are not safe:
#define DELTA_TICKS sample_tick_value
// initialized somewhere in the code
DWORD dwStartTick = GetTickCount();
DWORD dwEndTick = GetTickCount() + DELTA_TICKS;
// The following function fails on a rollover.
BOOL no_compare_tick_difference()
{
if ( GetTickCount() > dwEndTick )
return ( TRUE);
return (FALSE);
}
The following code shows how to properly use GetTickCount by comparing tick differences. This code handles the rollover situation.
BOOL compare_tick_difference()
{
if ( (GetTickCount() – dwStartTick) > DELTA_TICKS)
return ( TRUE);
return (FALSE);
}
. Man muss explizit AfxEndThread gar nicht aufrufen. Man sollte einfach alle Threadfunktionen einfach durch return verlassen. Der Thread wird dann entsprechend der Funktion, die man beim Start gewählt hat auch terminiert. Dann bleibt – auch bei einer Änderung der Umgebung , ob nun mit oder ohne MFC.