Унаследоваться

А напрягать пользователя тем, что бы его шаблонный тип отвечал нашему специальному интерфейсу для сбора статистики нехочется. Даже если все это мы сделаем за него а ему нужно просто унаследоватся.

Я всегда делал так. Необходимости в шаблоне таска я вообще не вижу. Конкретная очередь работает с конкретными задачами (или ее наследниками). Этим интерфейсом ты гарантируешь наличие execute и cancel плюс имеешь возможность хранить много всякой инфы о задачах в т.ч. статистику. В самой очереди имеет смысл хранить только усредненную статистику по всем задачам.

UPD. И я вообще не понял смысла использования шаблона задачи. То есть одна очередь может работать с одной какой-то конкретной задачей что ли?

единственное что мне нужно от пользователя это execute, и то это только с логической точки зрения, и если его небудет то все будет работать, правда выглядеть странно :). Все остальное, включая cancel, deadline и еще много чего у меня опционально, и разрешается с использование шаблонов (mpl). Зачем так? для гибкости (что бы эту «очеред» каждый мог кастомизировать под себя, «включая» или «выключая» те или иные опции). Я правда не особо уверен в выгрыше вызова пустой функции против пустого виртуального метода, но так уже сделано.

Ну так а кто описывает пустую функцию cancel? В моем варианте весь интерфейс описывается в родителе, а тут? Могу представить только такой вариант:

template<typename T>
void cancel(T task){
 (void)task;}

А для нужных задач эта функция перегружается под нужный тип. Если так, я бы назвал это жутким извращением :)

есть функция cancel_hook шаблонная, которая с использованием mpl определяет наличие у типа метода cancel с определенной сигнатурой, если есть - зовет его, если нет - ничего не делает.

Пляски начинались от того что очередь у меня с приоритетами. А комуто они не нужны. Поэтому когда пользователь параметризирует очередь типом у которого нет метода int priority() в недрах используется простая queue, в противном set. Есть еще пару особенностей типа приоритетов. Для единообразия все вынесено в шаблоны.

Нечто похожее сделано в boost::multi_index_container, там правдо это нужно опеределять в качестве параметров шаблона. У меня так не получилось, слишком разношорстные особенности должна поддерживать очередь.

Я бы назвал такое решение неоправданно сложным с множеством слабых легко теряемых связей. «Обычное» решение через наследование задачи было бы намного понятней как в реализации, так и при эксплуатации, причем интерфейс пользовательской задачи не усложнился бы.

Ну а раз сделано так, самое гибкое наверное — в задачи, для которых нужна статистика, вводить специальное поле stats (структуру статистики), которую, при наличии, будет модифицировать очередь. Все получится в едином духе. Не знаю правда как mpl отреагирует на stats неправильного типа, я с этим никогда не работал.

сейчас так и сделано. И это неочень нравится.

А напрягать пользователя тем, что бы его шаблонный тип отвечал нашему специальному интерфейсу для сбора статистики нехочется. Даже если все это мы сделаем за него а ему нужно просто унаследоватся.

Где-то внутри очереди есть объект, который хранит ссылку на пользовательский эвент. Например, это может быть чанк в DLL. В чём проблема держать объект со статистикой в этом чанке? Или пушить pair<> с объектом статистики и ссылкой на эвент если нельзя залезть в реализацию очереди.