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

[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() перейдёт через ноль.

[themech.livejournal.com]

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

[mr-st.livejournal.com]

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

[1ceheart.livejournal.com]

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

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

[sbj-ss.livejournal.com]

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

[vp.livejournal.com]

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

[wlite.livejournal.com]

GetTickCount64

[eugene-ivanov.livejournal.com]

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