Корректен ли такой код:

Цитата

MyClass* Function() {     static MyClass TestClass;     return &TestClass; }

корректен. учитывай, что конструктор вызовется при первом обращении к функции.

Но если деструктор MyClass сделать приватным, то компилятор ругается.
Почему?

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

Ага, тогда почему идет обращение к деструктору????

при выгрузке модуля (например, завершении проги) вызываются деструкторы у всех статических объектов (у которых были вызваны конструкторы). Вот только порядок вызова ничем не определен, что ставит под вопрос возможноcть использования этих объектов.

Да, но функция является дружественной классу и конструктор у меня в приватах.
Идея такова, что доступ к классу имеет одна функция. Типа Singleton.
Лучше приведу пример (наверное много глупостей, но это чисто тестовая конструкция):

Код

template<typename T>    void InitDispatch()  {    typedef cDispatcher<T> Dispatcher;    static Dispatcher Dispatch;    Dispatcher::m_Dispatcher=&Dispatch;    //static HANDLE hMutex;  }  template<typename T>    void DeInitDispatch()  {    typedef cDispatcher<T> Dispatcher;  }  template<typename T>    class cDispatcher    {    typedef cQueue<T> Queue;    typedef cDispatcher*  PDispatcher;    friend void InitDispatch();    friend void DeInitDispatch();    public:      ~cDispatcher() { cDispatcher::m_Dispatcher=NULL; } // Почему деструктор в пабликах должен быть???     inline static cDispatcher* Instance() { return cDispatcher::m_Dispatcher; }     void Dispatch()     {       printf("\nDispatch");     };    protected:    private:      cDispatcher(){};      cDispatcher(const cDispatcher&);      static cDispatcher*  m_Dispatcher;      Queue m_Queue;    };  template<typename T>    cDispatcher<T>::PDispatcher cDispatcher<T>::m_Dispatcher=NULL;

Цитата

(наверное много глупостей, но это чисто тестовая конструкция):

Да глупостей много, начиная уже с первых двух строк

template<typename T>
void InitDispatch()
{
}

А что кроме как делать private деструктор выхода из ситуации нет?
Може там где ты объявляешь дружественную функцию, и где функцию описываешь разные прототипы в этом легко напортачить особенно с шаблонами?

Цитата(AndyY @ 31.5.2004, 15:52)

при выгрузке модуля (например, завершении проги) вызываются деструкторы у всех статических объектов (у которых были вызваны конструкторы). Вот только порядок вызова ничем не определен, что ставит под вопрос возможноcть использования этих объектов.

правило в C++: последним создан, первым уничтожен.

Добавлено @ 18:36
элегантный шаблон Singletone (вроде предложен Майерсом, может я ошибаюсь)
template <class T>
T * Singletone()
{
static T s;
return &S;
}

Это сообщение отредактировал(а) achmed - 1.6.2004, 13:25

achmed
правило прописано в стандарте? IMHO это просто конкретная реализация CRT (статические объекты складываются в какой-то список).
один фиг юзать невозможно, поскольку никто не знает последовательность создания. Да и удобство сомнительное.

btw а почему не сделать деструктор protected?

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

Nastya

Цитата

Да глупостей много, начиная уже с первых двух строк template<typename T> void InitDispatch() { }

А что глупого в этих строчках?

Цитата

template<typename T> void InitDispatch() {   typedef cDispatcher<T> Dispatcher;   static Dispatcher Dispatch;   Dispatcher::m_Dispatcher=&Dispatch; }

Обясните пожалуйста. Не вижу ничего странного в строчке template<typename T> void InitDispatch()

Цитата

зачем столько кода, который не делает ничего? неужели он хоть раз помог кому-то помог избежать ошибки?

Это хочу настраиваемый диспетчер сообщений забомбить

bel_nikita
А что такое диспатчер сообщений? Могучий фильтр на DispatchMessage:)) или NotifyController наподобии java?

Все-же не пойму, зачем так сложно.
кстати, приведу пример - как сделано у меня:

Код

template <class _class> class _static_pointer_t { public:    _static_pointer_t()    {    _assert( static_ptr() == 0 );  static_ptr() = (_class*)this;     }    ~_static_pointer_t()    {        static_ptr() = 0;    } public:    static _class  *&static_ptr()    {static _class  *pclass = 0;return pclass;} }; class module : public _static_pointer_t<module> ...

и обращаешься:
module *p = module::static_ptr();
...

это конечно далеко от совершенства, но ситуаций с ошибкой в коде связанной с этой конструкцией не было. зачем делать больше?

Цитата

А что такое диспатчер сообщений?

В проге есть различные объекты. У каждого свой тип (TypeObject) и идентификационный номер (ID). И все объекты должны обмениваться сообщениями между собой. Т.е. есть некий виртуальный базовый класс с функцией, типа ProcessMessage(Message). А диспетчер должен управлять сообщениями. То бишь есть глобальная очередь сообщений, куда все объекты, производные от базового, складывают свои события. Диспетчер фильтрует, например в отдельном треде, сообщения и вызывает виртуальную функцию ProcessMessage(Message) для объекта, которому предназначено данное сообщение.
Вот, такая вот не хитрая конструкция
Че-та написал, не знаю, понятно ли?

bel_nikita
интересная задача.
тред я пожалуй не стал бы пускать - тормозить будет. или он или интерфейс... А вот обработчики в разных тредах - есть над чем подумать.
а почему базовый класс виртуальный?

и зачем вообще вся тема с синглетоном - ведь понятно, что диспатчер один...
а если он не один будет - грубо говоря в другом окне потребуется другая чехарда с объектами? обломс с синглетоном.

Цитата

а почему базовый класс виртуальный?

Не правильно изложил мысль. Не виртуальный, а абстрактный.

Цитата

и зачем вообще вся тема с синглетоном - ведь понятно, что диспатчер один...

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

Еще вот,что: я не под WIN32 сижу. Так, что окна мне не страшны

Вот, приведу еще пример базового класса:

Код

template<typename T> class cDispatcher;  /************************************************************************/  /* class cBase                                                          */  /************************************************************************/  template<typename Message, class TypeObject=DWORD, class IdObject=DWORD>    class cBase    {      typedef std::pair<TypeObject,IdObject> PAIR;      typedef cBase<Message>*  PBASE;      friend class cDispatcher;    public:      typedef std::map<PAIR,PBASE> MAP;                  cBase(const TypeObject& TypeObj, const IdObject& IdObj);      virtual ~   cBase();      TypeObject  GetType() const { return m_ID.first; }      IdObject    GetID() const { return m_ID.second; }      //virtual BOOL  ProcessMessage(const Message&)=0;          protected:      PAIR m_ID;    private:      static MAP  m_staticMap;    };  template<typename Message, class TypeObject, class IdObject>    cBase<Message, TypeObject, IdObject>::MAP    cBase<Message, TypeObject, IdObject>::m_staticMap;  /*   * CONSTRUCTOR   */  template<typename Message, class TypeObject, class IdObject>    cBase<Message, TypeObject, IdObject>::    cBase(const TypeObject& TypeObj, const IdObject& IdObj)  {    PAIR Temp=std::make_pair(TypeObj,IdObj);    m_staticMap.end();    if ( cBase::m_staticMap.find(Temp) != cBase::m_staticMap.end() )  // ELEM EXIST    {      //std::out_of_range("Elem exist");    }    else      cBase::m_staticMap.insert( MAP::value_type(m_ID=Temp, this) );  }  /*   * DESTRUCTOR   */  template<typename Message, class TypeObject, class IdObject>    cBase<Message, TypeObject, IdObject>::~cBase()  {    MAP::iterator i=cBase::m_staticMap.find(m_ID);    if ( i != cBase::m_staticMap.end() )                             // ELEM EXIST      cBase::m_staticMap.erase(i);    else      throw ("BRED");  }

Мысля такова:
Если создается объект, производный от базового класса, то поитер заносится в статический МАР. А когда диспетчер имеет сообщение, то он бежит по этому МАРу и отыскивает нужный объект(т.е. которому предназначено сообщение) и вызывает виртуальный метод ProcessMessage(const Message&).
А если объект, производный от базового, удаляется, то базовый деструктор удаляет свой поитер из МАР. Т.е. можно динамически создавать и удалять объекты в процессе работы проги. И все они могут свободно обмениваться событиями между собой.
Вроде так
Но, вот подумал. А если этих объектов пару тысяц будет? Долго искать придется

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

Цитата

когда диспетчер имеет сообщение, то он бежит по этому МАРу и отыскивает нужный объект(т.е. которому предназначено сообщение) и вызывает виртуальный метод 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 обработки событий.......