Отличнейший баг

[metaclass]

Откопал только что в проге сабж. Совершенно безумный.

Есть у меня в проге отображение прогресса для длинных операций. Чтобы его постоянно не обновлять, я вывожу изменения только через каждые 0.3 секунды. А проверяю это дело, использую функцию GetTickCount, сохраняя ее предыдущее значение и сравнивая с текущим. Если разница >300 то прогресс обновляется.

Оказалось, что комп на работе не выключался столько, что GetTickCount стал меньше нуля (использовался integer). И сей алгоритм сломался, т.е. прогресс перестал показываться вообще. Дома показывается, тут нет.

Comments

[adews.livejournal.com]

А как-же сохранение энергии и забота об экологии? ;-)

[eu3eu.livejournal.com]

А я пользую такой способ.
Результат DWORD-DWORD будет DWORD. Поэтому вычисление:

DWORD tstart = GetTickCount();
...
if ( ( GetTickCount() - tstart ) >= 300 ) ...

будет всегда нормально работать, даже, когда GetTickCount() перейдёт через ноль.

[metaclass.livejournal.com]

Хехе, у меня там было более хитро. tstart назначался не всегда, в чем собственно и баг. Когда он был 0 и GetTickCount>0 - все работало. А когда GetTickCount cтал меньше нуля, все сломалось :)

[eu3eu.livejournal.com]

Лично я стараюсь не пользовать типы со знаком там, где в этом нет надобности - в индексах, в счётчиках на инкремент.

[eu3eu.livejournal.com]

А GetTickCount возвращает DWORD (unsigned long), зачем было делать каст в int?

[metaclass.livejournal.com]

а, осталось от каких-то дико стародавних пор

[themech.livejournal.com]

это только старые программисты при имеющихся сейчас в наличии безумных объемах памяти экономят 2 байти на переменной? светлая память о 640 кБ ОЗУ? ;-)

[metaclass.livejournal.com]

4 байта переменной с микросекундами. Винда так возвращает. 49 дней период, если целиком все диапазон, а если до минуса просто дожидаться - то и 24 дня.

[themech.livejournal.com]

все понятно. в микрософте никогда не предполагали что винда может работать более 24 дней без перезагрузки ;-)

[mr-st.livejournal.com]

Знакомая штука.Правда мне задетектить его было проще т.к. клиент жаловся на заисание когда меняешь время. По тикам fps ограничивался.

[1ceheart.livejournal.com]

Ну это вообще классическая бага. Особенно на микроконтроллерах, где 32-битный счетчик особо не зафигачишь.

Поэтому, как справедливо заметил предыдущий оратор, if ((now - since) > 300) - работает всегда.

[sbj-ss.livejournal.com]

А просто обновлять прогрессбар каждые N операций религия не позволяет? :)

[metaclass.livejournal.com]

Операций может быть 10000 в секунду, а может быть 10 в секунду. Каждые N тут не покатит, если N не рассчитывать какими нибудь эвристическими методами. А вот 3 раза в секунду вполне прилично.

[vp.livejournal.com]

все то же самое, но разницу между прошлым и текущим значениями смотреть по модулю

[metaclass.livejournal.com]

Юникс-вей запрещает обходить баги :)

[wlite.livejournal.com]

GetTickCount64

[kkirsanov.livejournal.com]

GetTickCount64 - подари бак потомкам! :)

[kkirsanov.livejournal.com]

баг конечно же.

[wlite.livejournal.com]

угу :)
кстати, по реквирементс оно тока на висте поедет, не считая самописного варианта с исходников ру
ну можно еще GetSystemTimes юзать. или еще что-нибудь более сложное, чтоб этот баг затмили другие.

[kkirsanov.livejournal.com]

Кстати от таймерах.
Недавно боролся с глюками одной роботизированной хрени.
Там время мерили GetTickCount.

Вот табличка замера времени выполнения Sleep(100) GetTickCount против QueryPerformanceCounter

GetTickCount: 94 ms QPC: 100.246 ms
GetTickCount: 110 ms QPC: 100.173 ms
GetTickCount: 93 ms QPC: 100.156 ms
GetTickCount: 110 ms QPC: 100.281 ms
GetTickCount: 93 ms QPC: 100.083 ms
GetTickCount: 110 ms QPC: 100.127 ms
GetTickCount: 94 ms QPC: 99.7211 ms

[eugene-ivanov.livejournal.com]

помню, тоже подобный счётчик был. но там я ввёл проверку на переполнение, хотя время достижения оного было много-много лет ;) маньяк типа