Кстати, стандарт языка Си говорит, что переполнение знаковых целых - это "undefined behaviour", в отличие от беззнаковых, где всё хорошо в этом плане.


Ну тогда вставьте в код assert(days <= 25). Когда наступите на эти грабли, хотя бы табличка перед носом будет :-)

да тут не вопрос диапазона, а вопрос постановки задачи....

ожидание конкретного времени == выдерживанию интервала. А интервал вычисляется без потери диапазона, но требует доп. переменной, то есть вам приходиться хранить Interval == (NeedTime - Start) и Start. Вроде как 4 байта при современных объемах памяти не большая беда...

Вычисляя разность между текущим значением таймера и начальным, мы сдвигаем точку отсчета в положение Start. И уже относительно нее определяем текущее значение таймера, и сравниваем с требуемым. Аналогичного эффекта можно добиться, если сбрасывать таймер перед запуском. Но так, как предложено, можно на одном таймере задавать сразу несколько задержек.

Да, цель именно выжать максимальную оптимизацию как по времени так и по памяти. В нынешних железах это конечно не принципиально. Но просто хочет это мой внутренний перфекционист. А использовать таймер на 25 дней - это как-то странно по моему. Для таких масштабов есть RTC.
P.S. Да и топик стартер вопрашал именно про юзанье одного счётчика для неограниченного кол-ва таймаутов, задержек и т.п.

Пипец! Не ожидал такого мусоленья здесь совершенно очевидных вещей...

Получается, что это чисто теоретическое упражнение. И правильное решение одно: ассемблер.
А на практике за такие потуги надо очень больно бить по рукам, ибо, как известно, "преждевременная оптимизация - корень всех зол".


Не спешите. В очень многих кортексах есть счётчик циклов DWT_CYCCNT, и он очень удобен для этих самых задержек. Причём в МК из серии LPC43xx с частотой 204 МГц он переполняется каждые 21 сек.

jcxz, вы предложили то же самое: использовать 2 переменных. scifi, почему же она преждевременная? я оптимизировал конкретный конечный функционал, разобрался в вопросе до конца и тщательно вдоль и поперёк оттестировал решение. Побейте тогда по рукам ещё и создателей библиотек которые оптимизируют свои творения до применения в реальных проектах. Какая-то странная логика. Счётчик циклов использую для измерений требуемых максимальную точность (единицы или десятки микросекунд, в зависимости от частоты). Но при чём тут он, не понятно?

Сообщение отредактировал Ruslan-maniak - Oct 29 2014, 03:42

Где Вы углядели 2-ю? Вроде всего одна: t.


scifi Вам дело говорит.
1. Кто занимается оптимизацией инкремента переменной , не пишут реальных проектов.
2. Кто пишет реальные проекты, не занимаются оптимизацией инкремента.

Считайте по пальцам из вашего примера: переменная "t" - РАЗ, переменная "TOUT" - ДВА. Про второй пункт вашего поста я промолчу.

Давайте поглядим
Плюсы минусы вашей оптимизации

Минусы
1. Меньший диапазон возможных значений в 2 раза
2. Строго говоря есть необходимость отметить это в документации, и возможные ошибки при использовании функции тем кто не в курсе.
3. Поскольку потери случаются на длинном конце использования, то еще долгий процесс выявления ошибки
4. Необходимость кучи объяснений почему вы сделали так а не иначе в коде

Плюсы
1. Вы выиграли 4 байта памяти. Даже если взять древний проц с каким нибудь 2 КБайтами памяти, то вы выиграли ~0.2% ресурса с каждого таймера. Для обычных кортексов с 48 Кбайтами 0.008%

В целом неплохо потрудились

1. Вы реально использовали миллисекундный таймер для замера интервала времени больше 25 дней?! О_о
2. Относится к первому пункту.
3. Потери НЕ СЛУЧАЮТСЯ ни в теории, ни на практике - провёл огромное кол-во тестов. Если вы считаете что возможны потери - приведите пример (буду искренне рад если вы поможете избежать этих потерь. если они возможны).
4. Кому и что нужно объяснять? По этой логике нужно объяснять и любой другой вариант.

1. Я писал что практическая ценность никакая от этого. Но именно это решение является решением для задачи поставленной топикстартером.

Сообщение отредактировал Ruslan-maniak - Oct 29 2014, 05:45

С чего вы взяли что TOUT это обязательно переменная???
Под TOUT имелось в виду выражение. Откройте любой учебник по си чтобы узнать значение термина expression.

1. Почему нет, я участвовал в разработке системы которая работала автономно несколько лет без сбоев, повисаний, перезагрузок. При этом у нее был миллисекундный таймер для внутреннего времени (по ряду причин РТС использовать было нельзя), и почему бы раз в месяц этой системе не синхронизировать с центром время, данные и прочее?
1.1. Вы пишите что-то только один раз? На реюзинг не рассчитываете? Почему вы уверены что ваш код не запустят для микросекундного или наносекундного таймера?

2. Вы не застали замечательную ошибку паскаля который для delay в начале работы программы делал калибровку. Он брал цикл в сколько-то тактов и считал сколько милсекунд ушло на него, потом делил одно на другое и получал калиброванное значение чтобы точнее делать delay. Где то в районе 90 годов, все программы сделанные на этом паскале хором перестали работать. Потому что частота процов так возросла, что отведенный цикл стал выполнятся за 0 мСек, и деление на 0 давало ошибку. Уверен что те кто писал библиотечную функцию тоже заложились что процы же не станут в 1000 раз быстрее)

Мораль - потенциально кривое решение, рано или поздно вылезет, так что если есть какие-то ограничения они должны быть обложены асертами, описанием и прочее. В противном случае выгода от оптимизации нивелируется потенциальными граблями. Это как фасад здания покрасить, а внутри помойку устроить.

3. Сделайте вашим методом паузу больше половины интервала. Там можно так исхитриться что при заданной частоте проверок и интервале, оно будет так переполнятся что в 90% случаев все будет ок, а в 10% будет второй круг. И его ловить - это задача с подвохом...

4. странные и не очевидные ходы требует больше слов для их оправдания...


решение для ТС приведено сразу же в начальных постах, оно его устроило и оно является очевидно правильным.

У меня тут тоже с коллегами разгорелся спор, можно ссылку на стандарт с упоминанием этой гарантии, не могу найти.

В стандарте С (6.2.5.9) есть такой текст:

А стандарт С++ в (3.9.1) содержит такой текст:

и ниже примечание, совпадающее по смыслу с текстом из стандарта С, про арифметику по модулю 2ⁿ.

Впрочем всё это фигня и словесная эквилибристика.
А правда жизни состоит в том, что все эти свойства и поведение знаковых и беззнаковых типов диктуются устройством АЛУ и принятым в подавляющем большинстве современных машин представлением знаковых целых в так называемом "двоичном коде с дополнением до 2".
Преимущество такого представления - то что АЛУ работает совершенно одинаково, а разница signed/unsigned учитывается только при интерпретации признаков переполнения и переноса ( C и V ), и при многоразрядной арифметике, для правильно учёта переноса из младшего слова в старшее.
Изначально С неявно предполагал именно такое представление целых (как и сделано в PDP-11, на которых он изначально появился). Альтернативные представления уже тогда были редкостью.
Все более поздние изменения стандартов в части целочисленной арифметики и сдвигов просто витиевато выражают простую мысль: "делайте что хотите, но результат должен быть такой же как на "нормальных" процессорах использующих код с дополнением до двойки".

То есть сначала было придумано АЛУ, работающее с неотрицательными целыми числами, потом придумано как представлять отрицательные числа так, чтобы не переделывать АЛУ, а уж потом сочинители стандартов попытались описать что получилось так как они умеют это делать.