C ++ Singleton дизайн шаблона

Будучи Singleton, вы обычно не хотите, чтобы он был разрушен.

Он будет разорван и освобожден, когда программа завершится, что является нормальным желаемым поведением для одноэлементного. Если вы хотите явно очистить его, довольно легко добавить статический метод в класс, который позволит вам восстановить его в чистое состояние и перераспределить его в следующий раз, когда он будет использоваться, но что вне сферы действия "классический" синглтон.

Вы можете избежать выделения памяти. Существует много вариантов, все из которых имеют проблемы в случае многопоточной среды.

Я предпочитаю такую ​​реализацию (на самом деле, я не правильно сказал, что предпочитаю, потому что я избегаю синглетонов как можно больше):

class Singleton
{
private:
   Singleton();

public:
   static Singleton& instance()
   {
      static Singleton INSTANCE;
      return INSTANCE;
   }
};

У него нет динамического распределения памяти.

Другая альтернатива без выделения: создайте одноэлементный, скажем, класс C, как вам это нужно:

singleton<C>()

используя

template <class X>
X& singleton()
{
    static X x;
    return x;
}

Ни тот, ни ответ Cătălin автоматически не потокобезопасны в текущем С++, но будут в С++ 0x.

@Локи Астари ответ отлично.

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

В этом случае std::shared_ptr можно использовать, чтобы поддерживать одножильный режим для всех пользователей, даже когда статические деструкторы вызывают в конце программы:

class Singleton
{
public:
    Singleton(Singleton const&) = delete;
    Singleton& operator=(Singleton const&) = delete;

    static std::shared_ptr<Singleton> instance()
    {
        static std::shared_ptr<Singleton> s{new Singleton};
        return s;
    }

private:
    Singleton() {}
};

Если вы хотите выделить объект в кучу, почему бы не использовать уникальный указатель. Память также будет освобождена, так как мы используем уникальный указатель.

class S
{
    public:
        static S& getInstance()
        {
            if( m_s.get() == 0 )
            {
              m_s.reset( new S() );
            }
            return *m_s;
        }

    private:
        static std::unique_ptr<S> m_s;

        S();
        S(S const&);            // Don't Implement
        void operator=(S const&); // Don't implement
};

std::unique_ptr<S> S::m_s(0);

Вот простая реализация.

#include <Windows.h>
#include <iostream>

using namespace std;


class SingletonClass {

public:
    static SingletonClass* getInstance() {

    return (!m_instanceSingleton) ?
        m_instanceSingleton = new SingletonClass : 
        m_instanceSingleton;
    }

private:
    // private constructor and destructor
    SingletonClass() { cout << "SingletonClass instance created!\n"; }
    ~SingletonClass() {}

    // private copy constructor and assignment operator
    SingletonClass(const SingletonClass&);
    SingletonClass& operator=(const SingletonClass&);

    static SingletonClass *m_instanceSingleton;
};

SingletonClass* SingletonClass::m_instanceSingleton = nullptr;



int main(int argc, const char * argv[]) {

    SingletonClass *singleton;
    singleton = singleton->getInstance();
    cout << singleton << endl;

    // Another object gets the reference of the first object!
    SingletonClass *anotherSingleton;
    anotherSingleton = anotherSingleton->getInstance();
    cout << anotherSingleton << endl;

    Sleep(5000);

    return 0;
}

Создается только один объект, и эта ссылка на объект возвращается каждый раз.

SingletonClass instance created!
00915CB8
00915CB8

Здесь 00915CB8 - это ячейка памяти singleton Object, то же самое в течение всей программы, но (обычно!) различна при каждом запуске программы.

N.B. Это не безопасный поток. Вы должны обеспечить безопасность потока.

Решение в принятом ответе имеет существенный недостаток - деструктор для singleton вызывается после того, как элемент управления покидает "главную" функцию. На самом деле могут возникнуть проблемы, когда некоторые зависимые объекты выделяются внутри "main".

Я встретил эту проблему, пытаясь ввести Singleton в приложение Qt. Я решил, что все мои диалоги настройки должны быть Singletons, и приняли шаблон выше. К сожалению, основной класс Qt "QApplication" был выделен в стеке в "основной" функции, а Qt запрещает создавать/уничтожать диалоги, когда объект приложения недоступен.

Вот почему я предпочитаю выделенные в кучу синглтоны. Я предоставляю явные методы "init()" и "term()" для всех синглтонов и называю их внутри "main". Таким образом, у меня есть полный контроль над порядком создания/уничтожения одиночек, а также я гарантирую, что будут созданы синглтоны, независимо от того, кто-то назвал "getInstance()" или нет.

На самом деле это, вероятно, выделено из кучи, но без источников нет возможности узнать.

Типичная реализация (взятая из некоторого кода, который у меня есть в emacs уже):

Singleton * Singleton::getInstance() {
    if (!instance) {
        instance = new Singleton();
    };
    return instance;
};

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

Если вы работаете на платформе, где очистка должна выполняться вручную, я бы, вероятно, добавил ручную процедуру очистки.

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

Кто-нибудь упомянул std::call_once и std::once_flag? Большинство других подходов, включая двойную проверку блокировки, нарушены.

Одной из основных проблем в реализации одноэлементного шаблона является безопасная инициализация. Единственный безопасный способ - защитить последовательность инициализации синхронизирующими барьерами. Но сами эти барьеры должны быть безопасно начаты. std::once_flag - это механизм, гарантирующий безопасную инициализацию.

Я не нашел CRTP-реализацию среди ответов, так вот вот:

template<typename HeirT>
class Singleton
{
public:
    Singleton() = delete;

    Singleton(const Singleton &) = delete;

    Singleton &operator=(const Singleton &) = delete;

    static HeirT &instance()
    {
        static HeirT instance;
        return instance;
    }
};

Чтобы просто наследовать свой класс, например: class Test : public Singleton<Test>

Речь идет об управлении жизненным временем объекта. Предположим, что у вас в вашем программном обеспечении больше, чем однопользовательских. И они зависят от Singleger Logger. Во время уничтожения приложения предположим, что другой одноэлементный объект использует Logger для регистрации шагов его уничтожения. Вы должны гарантировать, что Logger должен быть очищен последним. Поэтому, пожалуйста, также ознакомьтесь с этой статьей: http://www.cs.wustl.edu/~schmidt/PDF/ObjMan.pdf

Простой одноэлементный класс, это должен быть ваш файл класса заголовка

#ifndef SC_SINGLETON_CLASS_H
#define SC_SINGLETON_CLASS_H

class SingletonClass
{
    public:
        static SingletonClass* Instance()
        {
           static SingletonClass* instance = new SingletonClass();
           return instance;
        }

        void Relocate(int X, int Y, int Z);

    private:
        SingletonClass();
        ~SingletonClass();
};

#define sSingletonClass SingletonClass::Instance()

#endif

Получите доступ к вашему синглтону следующим образом:

sSingletonClass->Relocate(1, 2, 5);

Здесь много ответов, и это было задано некоторое время назад, но я хотел бы добавить следующее. Благодарим Алана и Пола Эзуста. (Вступление к разработке шаблонов на С++ с Qt)

Шаблон Singleton является специализированным factory, используемым в ситуациях, когда вы хотите ограничить количество или тип созданных экземпляров. Метод CustomerFactory:: instance(), определенный ниже, является примером o singleton factory. Он создает объект, если это необходимо, но только в первый раз, когда этот метод вызывается. При последующих вызовах он всегда возвращает указатель на тот же объект.

CustomerFactory* CustomerFactory::instance(){
   static CustomerFactory* retval = 0;
   if (retval == 0) retval = new CustomerFactory(qApp);          1
   return retval;
}

1 Обеспечивает очистку этого объекта и всех его дочерних элементов при выходе из QApplication.

При работе с объектами кучи важно не оставлять утечки памяти. Вы можете использовать отношения родитель-ребенок QObjects, чтобы помочь в этом отношении.

В дополнение к другому обсуждению здесь, возможно, стоит отметить, что вы можете иметь глобальность, без ограничения использования одного экземпляра. Например, рассмотрим случай ссылки, считая что-то...

struct Store{
   std::array<Something, 1024> data;
   size_t get(size_t idx){ /* ... */ }
   void incr_ref(size_t idx){ /* ... */}
   void decr_ref(size_t idx){ /* ... */}
};

template<Store* store_p>
struct ItemRef{
   size_t idx;
   auto get(){ return store_p->get(idx); };
   ItemRef() { store_p->incr_ref(idx); };
   ~ItemRef() { store_p->decr_ref(idx); };
};

Store store1_g;
Store store2_g; // we don't restrict the number of global Store instances

Теперь где-то внутри функции (например, main) вы можете сделать:

auto ref1_a = ItemRef<&store1_g>(101);
auto ref2_a = ItemRef<&store2_g>(201); 

Ссылкам refs не нужно сохранять указатель на соответствующий Store, потому что эта информация предоставляется во время компиляции. Вам также не нужно беспокоиться о времени жизни Store, потому что компилятор требует, чтобы он был глобальным. Если действительно существует только один экземпляр Store, то в этом подходе нет накладных расходов; с более чем одним экземпляром, до компилятора, чтобы быть умным в генерации кода. Если необходимо, класс ItemRef может быть даже сделан friend из Store (у вас могут быть шаблонные друзья!).

Если Store сам является шаблоном, тогда все становится более беспорядочным, но все же можно использовать этот метод, возможно, путем реализации вспомогательного класса со следующей сигнатурой:

template <typename Store_t, Store_t* store_p>
struct StoreWrapper{ /* stuff to access store_p, e.g. methods returning 
                       instances of ItemRef<Store_t, store_p>. */ };

Теперь пользователь может создать тип StoreWrapper (и глобальный экземпляр) для каждого глобального экземпляра Store и всегда обращаться к хранилищам через свой экземпляр оболочки (таким образом забывая о деталях gory параметров шаблона, необходимых для использования Store).

#define INS(c) private:void operator=(c const&){};public:static c& I(){static c _instance;return _instance;}

Пример:

   class CCtrl
    {
    private:
        CCtrl(void);
        virtual ~CCtrl(void);

    public:
        INS(CCtrl);

Документ, который был связан с выше, описывает недостаток блокировки с двойной проверкой - это то, что компилятор может выделить память для объекта и установить указатель на адрес выделенной памяти до того, как был вызван конструктор объекта. В С++ довольно просто использовать распределители для распределения памяти вручную, а затем использовать конструктивный вызов для инициализации памяти. Используя эту оценку, двойная проверка блокировки работает очень хорошо.

Я думаю, что вы должны написать статическую функцию, в которой ваш статический объект удален. Вы должны вызвать эту функцию, когда собираетесь закрыть приложение. Это обеспечит утечку памяти.

Как насчет использования нового размещения следующим образом:

class singleton
{
    static singleton *s;
    static unsigned char *buffer[sizeof(singleton)/4 *4] //4 byte align
    static singleton* getinstance()
    {
        if (s == null)
        {
            s = new(buffer) singleton;
        }
        return s;
    }
};