НА примере XP дискретность 100 наносекунд. Инкрементируется на время периода системного тика.

если 100 нан, то переполнение через 58.5 тыс лет.

Лично я рассчитываю что мои устройства спокойно преодолеют этот рубеж)

Во-первых, покажите в моём примере, где "значения приводятся к типу int (он же int64_t)"
Во-вторых, смотрите на вариант с unsigned int (правда, уже gcc 4.8.1), на всякий случай - 64-битные регистры те, что на букву r:

но конечно, это кривой пример, так как разность двух беззнаковых больше 0 и компилятор прав, что использует здесь проверку на равенство.
а вот при сравнении беззнакового числа с результатом вычитания двух беззнаковых чисел (как в итоге сделал ТС) компилятор использует кондишн "больше или равно" в беззнаковом варианте и всё работает

Чего там показывать? Это неявное приведение. Почитайте какую-нибудь книжку про язык Си. Ищите "integer promotion".

НО в данном способе (с вычитанием) мы должны гарантировать это вычитание каждую миллисекунду. А иначе есть шанс прошляпить равенство таймера и счётчика и тогда всё посыпется. Ведь так?

Надо проверять не равенство, "а больше или равно" или "меньше или равно" - что подходит по контексту.

В этом и заключается мой вопрос. В приведённом примере вычитания - нет сравнения. Там только вычитание. И срабатывает оно только тогда когда именно равенство между счётчиком и таймером. А если использовать сравнение, то опять же упираемся в переполнение счётчика. Так как красиво то сделать?

Сообщение отредактировал Ruslan-maniak - Oct 28 2014, 10:22

Есть. Нужно разницу сравнить с нулем (не на равенство...).

На практике получается что если от меньшего беззнакового отнять большее беззнаковое то результат получается больше нуля, что собственно не удивительно. И данная конструкция не работает. Конечно если гарантировать программе что проверку она будет совершать точно каждую миллисекунду, то всё будет нормально. Но я бы не стал оставлять это на авось. На данный момент пришёл к такому решению: приводить разность перед сравнением к знаковому типу. И тогда всё нормально - обмануть таймер не получается какие бы значения счётчика не брать за начальные. Что об этом думаете?

вы про какой из примеров то?

return(TSysTimer::Counter - StartCount >= Interval); - возвращается не разница, а результат сравнения.

У вас есть время начала и текущее время, их разность всегда есть интервал прошедшего времени. Проблемы только рассчитать интервал больше либо равный максимальному значению счетчика, потому что в этом случае после Максимум - 1, будет следовать 0, из-за переполнения. Но с этим ничего не сделаешь, кроме моего варианта
в прерывании таймера считать назад...


думаем что вы не правы

допустим у нас беззнаковое число 4 бита, для удобства

все его значения
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15

берем любое начало, допустим 7.
все значения от 8 до 15, не вызывают вопросов 8-7 = 1,... 15-7 = 8, честно получаем время прошедшие от 7 до текущего значения.

идем дальше, счетчик переполнился и получилось
0, 0 - 7 == -7, как это представлено в битах? 1001, а что это в беззнаковом числе? О чудо это 9

15-7 = 8, 0 - 7 = 9, 1 - 7 == - 6 (1010) == 10 и так далее, до

6 - 7 = -1 (1111) = 15;

то есть до полного цикла счетчика все переполнения отрабатываются правильно)

Вот взяли мы это 7, и хотим что бы таймер сработал когда счётчик дойдёт до 12. И вы предлагаете вычитать 12 - 7 и сравнивать это с нулём, но так случилось что итерация 12 - 12 не случилась 12 - 11, а за ней уже 12 - 13, и та и другая даёт результат большей нуля в битовом выражении. И получается таймер не сработал тогда когда нужно. Разве нет?

Сообщение отредактировал Ruslan-maniak - Oct 28 2014, 11:01

Не так (я неправильно написал выше). Вам нужен интервал 5 (12 - 7). Текущее (стартовое) значение 7, запоминаете его. Дальше читаете значение таймера, отнимаете запомненное стартовое, и сравниваете разность с нужным интервалом.

Но таким образом на каждый случай приходится по 2 переменных: стартовое время и интервал. Если же использовать приведение разности (значение срабатывания - счётчик) к знаковому типу и сравнения получившегося с нулём, то одна переменная.

Тогда потеряете половину диапазона.

Да я как-то не рассчитываю использовать интервал более 25 дней



Сообщение отредактировал Ruslan-maniak - Oct 28 2014, 11:31