- 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;
}
govnomonad 08.10.2013 10:08 # −1
очередной неосилятор std::unique_ptr / auto_ptr
Так что говном я бы этот синглтон не назвал. А вот его использование точно говно
bormand 08.10.2013 11:47 # +3
Да почему. Реализация - говно ;)
> очередной неосилятор std::unique_ptr / auto_ptr
Да вполне можно было как с QApplication - тупо описать переменную где-то вверху main'а. Как раз и финализация вовремя сработает.
TarasB 08.10.2013 11:50 # 0
bormand 08.10.2013 12:09 # +1
guest 11.10.2013 14:38 # −12
bormand 08.10.2013 10:19 # +2
А глобальный GetInstance(), не являющийся методом класса, это эпично ;)
roman-kashitsyn 08.10.2013 10:25 # +1
bormand 08.10.2013 11:48 # 0
roman-kashitsyn 08.10.2013 12:00 # 0
Никогда не пробовал
guest 11.10.2013 14:38 # −12
Little-Horny 08.10.2013 10:23 # 0
А вообще, это не Singleton, а коряво реализованный Monostate.
Dummy00001 08.10.2013 13:33 # +4
Я где есть возможность все синглтоны в подобное конверчу (если нет возможности их убрать вообще). Решает самые главные проблемы: известный порядок инициализации синглтонов, обработка ошибок инициализации синглтона и передача параметров в инициализацию синглтона (которые иногда зависят от других синглтонов).
Так что меня сильно не удивит (не смотря на низкую вероятность) если ты в мой код смотришся. :D
bormand 08.10.2013 13:56 # +1
Dummy00001 08.10.2013 14:18 # 0
Xom94ok 08.10.2013 20:39 # +2
К тому же, такой подход в некоторой степени оберегает от ошибок коллег, не чурающихся глобально объявлять экземпляры класса :)
bormand 08.10.2013 21:20 # +1
Дык если этот синглтон не инициализировать (например в main'е как в моем примере выше), его же распидорасит на *s_instance:)
P.S. Все, спать пора. singleton_user описывают в каждом месте, где нужен доступ к синглтону. Поэтому все норм (ну в пределах однопоточной проги).
bormand 08.10.2013 21:26 # +1
Dummy00001 08.10.2013 22:41 # 0
"правильный" singletone_user есть на старом проекте. но там он играет роль энкапсуляции поднобностей реализации поддержки многопоточности. типа, схематический код:
bormand 08.10.2013 22:51 # 0
Хм. А это точно был синглтон?
Или здесь просто имеется в виду, что во время write лока все read локи отпущены, и код знает, что он единственный, кто в этот момент может работать с данным объектом.
Dummy00001 08.10.2013 22:59 # +1
bormand 08.10.2013 23:01 # 0
guest 11.10.2013 14:38 # −13
guest 08.10.2013 14:29 # 0
guest 08.10.2013 16:15 # 0
defecate-plusplus 08.10.2013 16:22 # 0