- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
// in .h file
class Singleton
{
public:
Singleton();
~Singleton();
private:
static Singleton* m_Instance;
friend Singleton& GetInstance();
};
inline Singleton& GetInstance()
{
assert(Singleton::m_Instance);
return *Singleton::m_Instance;
}
// in .cpp file
Singleton* Singleton::m_Instance = NULL;
Singleton::Singleton()
{
assert(!m_Instance);
m_Instance = this;
}
Singleton::~Singleton()
{
m_Instance = NULL;
}
Вот такую реализацию синглтона увидел в одном проекте.
ЗЫ: Для его корректной работы, в main было написано конечно же:
main() {
Singleton* s = new Singleton;
...
delete s;
}
очередной неосилятор std::unique_ptr / auto_ptr
Так что говном я бы этот синглтон не назвал. А вот его использование точно говно
Да почему. Реализация - говно ;)
> очередной неосилятор std::unique_ptr / auto_ptr
Да вполне можно было как с QApplication - тупо описать переменную где-то вверху main'а. Как раз и финализация вовремя сработает.
А глобальный GetInstance(), не являющийся методом класса, это эпично ;)
Никогда не пробовал
А вообще, это не Singleton, а коряво реализованный Monostate.
Я где есть возможность все синглтоны в подобное конверчу (если нет возможности их убрать вообще). Решает самые главные проблемы: известный порядок инициализации синглтонов, обработка ошибок инициализации синглтона и передача параметров в инициализацию синглтона (которые иногда зависят от других синглтонов).
Так что меня сильно не удивит (не смотря на низкую вероятность) если ты в мой код смотришся. :D
К тому же, такой подход в некоторой степени оберегает от ошибок коллег, не чурающихся глобально объявлять экземпляры класса :)
Дык если этот синглтон не инициализировать (например в main'е как в моем примере выше), его же распидорасит на *s_instance:)
P.S. Все, спать пора. singleton_user описывают в каждом месте, где нужен доступ к синглтону. Поэтому все норм (ну в пределах однопоточной проги).
"правильный" singletone_user есть на старом проекте. но там он играет роль энкапсуляции поднобностей реализации поддержки многопоточности. типа, схематический код:
Хм. А это точно был синглтон?
Или здесь просто имеется в виду, что во время write лока все read локи отпущены, и код знает, что он единственный, кто в этот момент может работать с данным объектом.