哇!什麼是一塊混淆的代碼。讓我們試圖簡化它:
// Calculate the delta
FILETIME delta;
delta.dwHighDateTime = ft_end->dwHighDateTime - ft_start->dwHighDateTime;
delta.dwLowDateTime = ft_end->dwLowDateTime - ft_start->dwLowDateTime;
// Convert 100ns units to double seconds.
double secs = delta.dwHighDateTime * 429.496 + delta.dwLowDateTime/1E7
實際上我認爲這是錯誤的。它應該是:
double secs = delta.dwHighDateTime * 429.4967296 + delta.dwLowDateTime/1E7
甚至更清楚:
double secs = (delta.dwHighDateTime * 4294967296. + delta.dwLowDateTime)/10E6
正在發生的事情是,高時間是由2**32
乘以(其轉化爲100ns單位再由100ns的分給秒。
注意,這是仍然錯誤,因爲delta
的計算是錯誤的(以同樣的方式爲原件)。如果低部分下溢的減法,它失敗從高位部分借錢。請參閱Microsoft的文檔:
不建議您從FILETIME結構中添加和減去值以獲取相對時間。相反,您應該將文件時間的低階部分和高階部分複製到ULARGE_INTEGER結構中,對QuadPart成員執行64位算術運算,並將LowPart和HighPart成員複製到FILETIME結構中。
或者實際上,在這種情況下,只需將QuadPart轉換爲double和divide即可。因此,我們最終用:
ULARGE_INTEGER start,end;
start.LowPart = ft_start->dwLowDateTime;
start.HighPart = ft_start->dwHighDateTime;
end.LowPart = ft_end->dwLowDateTime;
end.HighPart = ft_end->dwHighDateTime;
double duration = (end.QuadPart - start.QuadPart)/1E7;
題外話:我敢打賭,未能借從來沒有被發現是代碼從來沒有被要求打印大於7分9秒的持續時間的原因(或者,如果它沒有人仔細看過結果)。
如果你不知道它做了什麼,那麼你怎麼知道它工作正常? – user2079303
它給了我正確的結果。其實它是來自大學的實驗室工作,例如。但我想完全理解它。 –
您需要查看'FILETIME'的定義來弄清楚。這不符合語言標準。 ([looked](https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx),添加了winapi標籤。) – DevSolar