Здравствуйте, _cb_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>На каком лету, если можно обрабатывать только в правильном порядке, а его можно получить только получив и отсортировав все сообщения?
__>есть задачи в которых в принципе отсортировать по критерию (по времени например) нет возможности (например параллельная обработка сообщений в кластере). в подобных задачах сообщения не сортируют, а учитывают нужный критерий (время создания сообщения) в момент обработки. общих механизмов при в этом обычно не разрабатывают...
__>хотя возможно для вашей задачи все вышеописанное не нужно и сортировка прокатит...
в слове "учитывают" обычно собака и зарыта
На самом деле, целью моего поста не является обсуждение различных реализаций систем обработки сообщений — это слишком обширная тема и место ей не здесь, а в "Архитектуре".
Я ни в коем случае не утверждаю, что создал тут фреймворк на все времена.
Наоборот.
У меня была совершенно конкретная система, с которой я работал, и появилась совершенно конкретная задача, которую надо было решить, и ее удалось решить крайне просто и элегантно при помощи boost::mpl и boost::variant.
Просто о бусте бытует следующее представление:
1. Буст исключительно сложный
2. Некоторые библиотеки типа boost::mpl — с ними вообще простым смертным не разобраться
3. Чтобы использовать буст, надо вначале написать кучу трехэтажных шаблонов (особенно в случае boost::mpl), и как только ты их используешь, твой обычный код, который был бы без буста очень простым и коротким, теперь всегда будет горой шаблонов, текста будет в разы больше, и в основном нечитабельного.
4. Буст и особенно такие его части, как boost::mpl, простым прикладным программистам не нужны, они нужны только разработчикам библиотек.
Так вот целью моего поста было исключительно показать, что буста бояться не надо, даже таких страшных библиотек, как boost::mpl, и что при правильном применении они способны решать возникающие в жизни простого прикладного программиста задачи совсем без написания многоэтажных шаблонов и килобайтов кода, в котором полезной работой занимается всего одна строчка, а все остальные нужны только для того, чтоб всё вообще хоть как-то скомпилировалось и заработало (как я понимаю, этот "весь остальной код" называют модным словом boilerplate), и что код в результате получится прозрачный, понятный и простой, а старый код, который про буст ни сном ни духом, совершенно не пострадает.
В предлагаемом решении я вижу только одно место, которое можно отнести к boilerplate, т.е. которое ничего полезного не делает само по себе — это специализация оператора вызова функции для перехода от варианта к самим типам сообщений.
Все остальное служит для выражения определенных аспектов условия задачи (взятие определенного поля, упорядочение по определенному признаку в различных случаях).
А так, каждой задаче необходим свой подход, и не исключено, что если бы какое-то условие в задаче поменялось, я пришел бы в результате к совершенно другому решению.
