В общем , есть некое задание(для задачи не важно) которое должно исполниться в некое время
Время задается очень "широким форматом":
промежутки дней , дней недели , минут , часов. И также определенные значения, например:
в каждый понедельник , вторник и четверг , каждый 10 минут , каждого часа в 2008 году.

Вот думаю как лучше в данном случае писать планировщик ? 
На данный момент планировщик ЧЧ:ММ:СС сделан так:
Есть список с событиями , события сортируются по отдалению от текущего времени.
Далее отсчитывается время до ближ события , и таймер ожидает промежуток. Далее также до конца списка.

Но для первого случая данная схема не так легко применима(но вполне реализуема).

REZiaMIX, ну как мне кажется для начала непосредственного кодирования(программирования), необходимо определится с представлением твоего широкого формата

для какого первого случая?
вообще классически 2 схемы: 
1. ваша, с "переходом" на следующее событие 
2. таймер каждые N секунд (/минут/часов) с проверкой какие события надо активизировать

REZiaMIX, сделай одноразовый таймер с интервалом равным времени до ближайшего события, если это время меньше максимального, или с максимальным если больше.

Т.е. задание допустим может выполняться по след. условию времени:


По такому условию событие будет выполняться в 10 и 20 секунды , в 5 15 30 40 59 минуты , 12 - 14 часов(промежуток) 16 18 20 часы. Каждый понедельник, среду и пятницу. В любые числа месяца , но только 1,3,5 и 6-8(промежуток) месяцы. 

Добавлено @ 16:16

Каждую секунду проверять - не очень красивый выход.
Здесь больше вопрос в совместимости моего подхода с данной схемой промежутков времени.

Добавлено @ 16:17

В данный момент так и сделано , для первого случая где условия более простые.
(только точные секунды , минуты в независимости от других факторов)

Это сообщение отредактировал(а) REZiaMIX - 10.12.2009, 16:18

REZiaMIX, ну эти 2 схемы - это классика и я в них самих не вижу каких бы то ни было ограничений. вопрос в том насколько удачно тебе удастся реализовать функцию GetNextEventTime() при таком просторе в задании времен срабатывания событий.

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


Вот такая вот заготовка , в нее можно легко загнать все данные условия. Вот вопрос в том , как получить ближайшее время? Сортировать также все внутри каждого периода по отдалению от текущей даты. Получать для каждого CPeriod ближайшую внутреннюю дату , и потом уже среди списка сортировать все CPeriod ? 

ой. как спросишь. я ща насоветую, а те потом разгребать  
не, не берусь сказать. 
вариант - для каждого события рассчитать ближайшее время и отсортировать этот список мне лично импонирует (соответственно при срабатывании события высчитываем его следующее время срабатывания и вставляем в отсортированный список не нарушая сортировки. довольно элегантная схема и большие расчеты требуются только при запуске, когда анализируются все события)
лучше всего поэкспериментируй с 2-3 вариантами на прототипах и замерь какой вариант лучше. Заодно на прототипе вылезут все подводные камни рассматриваемых вариантов.

Спасибо , так и сделаю

Еще вариант:

•  Время срабатывания задается некоторой программой (в виде байт-кода) для стековой машины. 
•  Программа читает составляющие части даты/времени (отдельно месяцы, дни, часы и пр) и сравнивает их с заданными установками. (Перевод заданного диапазона времени срабатывания в байт-код довольно тривиален)
•  Программа составлена так, что более продолжительные части времени (годы, месяцы, дни, часы и т.д.) проверяются сначала
•  Вычисления выполняются по схеме short cut, т.е. если стало известно, что программа должна выдать 0, то она прерывается и выдает 0 немедленно, не вычисляя ничего дальше
•  Интерпретатор байт кода запоминает самую последнюю прочтенную составляющую времени
•  Если данная программа выдала 0, то снова она запускается на выполнение только когда значение, запомненное на предыдущем шаге, изменится

может все гораздо проще?

Человеку нужны были диапазоны и хитрые комбинации из разных диапазонов и точных дат/времени. boost::asio::deadline_timer с этим справится? Мне кажется, что нет   

xvr, я не проверял, но неудивлюсь если справится

Посмотрел на таймер в boost'е. Он поддерживает линейное понятие времени и не поддерживает никакие маски на временные интервалы. Так что это простой интервальный таймер. Автору никоим образом помочь не сможет, если только для отсчета заданных абсолютных интервалов. А превратить произвольную комбинацию масок времени в этот самый 'абсолютный интервал' и есть первоначальная проблема