Цитата

когда диспетчер имеет сообщение, то он бежит по этому МАРу и отыскивает нужный объект(т.е. которому предназначено сообщение) и вызывает виртуальный метод ProcessMessage(const Message&). А если объект, производный от базового, удаляется, то базовый деструктор удаляет свой поитер из МАР.

А если будет вот такая ситуация: диспетчер сообщений вызвал в своём треде ProcessMessage объекта A, но в процессе обработки мессаги объект A (в другом треде) вдруг прекратил своё существование (вызов деструктора, удаление пойнтера из MAP), то что тогда ? По идее, упасть должно

Цитата

А если будет вот такая ситуация: диспетчер сообщений вызвал в своём треде ProcessMessage объекта A, но в процессе обработки мессаги объект A (в другом треде) вдруг прекратил своё существование (вызов деструктора, удаление пойнтера из MAP), то что тогда ? По идее, упасть должно

Ага, точно. Критичная ситуация
Но синхронизация на что? Блокируем доступ к разделяемым ресурсам на время вызова ProcessMessage и изменения в МАРе.
А если диспетчер иммет мессагу, но этого объекта уже нет, то зачем это сообщение? Удаляем его из очереди....
Тут надо подумать...

Это сообщение отредактировал(а) bel_nikita - 1.6.2004, 14:17

2000 для нормальной мапы - пустяки, максимальный путь поиска - 11 сравнений (2048 элементов)
только вот криво это - если 2000 объектам нужно как-то реагировать на событие. Вот если 1-2 объекта - это понятно... А объекты одного типа лучше обрабатывать вместе (забавно посмотреть как реализован механизм нотификации через IConnectionPoint у микрософтов.

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

Цитата

еще раз вернусь к вопросу - нафига все-же синглетон? тем более с неочевидным синтаксисом.

Какие предложения есть? Через new... как-то не катит. Сделать все методы диспетчера статическими?...В принципе так и делаю

Цитата

А объекты одного типа лучше обрабатывать вместе

А это как? Не понял? Можно по-подробнее.

А по мне дык STLport - rulezzz

Как? ну, самое простое, в хидере:


class dispatcher
{
///методы
};
extern dispatcher g_disp;

в .cpp:
dispatcher g_disp;

и все!

про обработку:
например, у тебя 1000 объектов, которые нужно перерисовать (у них изменилось общее свойство). разумнее их перерисовать все скопом специализированной функцией, чем по одному (как минимум экономия на вызове виртуальной функции). Зачастую и алгоритм оптимизировать - например в windows 1000 вызовов Invalidate/UpdateWindow выполнятся намного медленней, чем для 1. В общем наличие большого числа листенеров сообщений - повод их объеденить в спец. менеджер, который и будет обрабатывать события для всех объектов вместе.

Подсказка: у 20-ти объектов одного и того же базового класса, скорее всего будет 20 однотипных обработчиков сообщений. Так что можно вместо внешнего класса сделать внутренний класс CMessageDispatcher, который будет обеспечивать обработку мессаг для всех классов, производных от данного (т.е. хранить MAP, вызывать ProcessMessage и т.п.).

Для генерации сообщения достаточно будет вызвать метод FireMessage любого объекта. Данный метод вызовет ProcessMessage объекта, и т.п. Реализация будет зависеть от реализации вирт. ф-ции FireMessage объекта (которая может делать всё что угодно - от простого вызова ProcessMessage данного объекта, до перебора всех элементов MAP данного объекта).

Идея, в общем-то простая. У каждого объекта есть набор однотипных свойств, поэтому есть набор однотипных событий, значит такие объекты могут быть объединены в один MAP обработки событий.......