Шаблон "одиночка" в C++

Вам, наверное, стоит прочитать книгу Александреску.

Что касается локальной статики, я какое-то время не использовал Visual Studio, но при компиляции с Visual Studio 2003 был выделен один локальный статический код для каждой DLL ... поговорим о кошмаре отладки, я запомню это по одному на время: /

1. Время жизни синглтона

Основная проблема синглтонов - это управление временем жизни.

Если вы когда-нибудь попытаетесь использовать объект, вы должны быть живы и здоровы. Таким образом, проблема возникает как из-за инициализации, так и из-за разрушения, что является распространенной проблемой в C ++ с глобальными объектами.

Обычно проще всего исправить инициализацию. Как предполагают оба метода, его достаточно просто инициализировать при первом использовании.

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

2. Локальная статика

struct A
{
  A() { B::Instance(); C::Instance().call(); }
};

struct B
{
  ~B() { C::Instance().call(); }
  static B& Instance() { static B MI; return MI; }
};

struct C
{
  static C& Instance() { static C MI; return MI; }
  void call() {}
};

A globalA;

В чем проблема? Давайте проверим порядок, в котором вызываются конструкторы и деструкторы.

Сначала этап построения:

• Выполняется globalA; , вызывается A :: A ()
• A :: A () вызовы B :: B ()
• A :: A () вызывает C :: C ()

Он работает нормально, потому что мы инициализируем B и Экземпляры C при первом доступе.

Во-вторых, фаза разрушения:

• C :: ~ C () вызывается, потому что он был построен последним из 3
• B :: ~ B () вызывается .. .oups, он пытается получить доступ к экземпляру C !

Таким образом, мы имеем неопределенное поведение при разрушении, хм ...

3.Новая стратегия

Идея здесь проста. встроенные глобальные модули инициализируются перед другими глобальными переменными, поэтому ваш указатель будет установлен на 0 до того, как будет вызван какой-либо из написанного вами кода, это гарантирует, что test:

S& S::Instance() { if (MInstance == 0) MInstance = new S(); return *MInstance; }

действительно проверит верен ли экземпляр.

Однако, как уже было сказано, здесь есть утечка памяти и, что хуже всего, деструктор, который никогда не вызывается. Решение существует и стандартизировано. Это вызов функции atexit .

Функция atexit позволяет указать действие, выполняемое при завершении программы. После этого мы можем написать синглтон:

// in s.hpp
class S
{
public:
  static S& Instance(); // already defined

private:
  static void CleanUp();

  S(); // later, because that's where the work takes place
  ~S() { /* anything ? */ }

  // not copyable
  S(S const&);
  S& operator=(S const&);

  static S* MInstance;
};

// in s.cpp
S* S::MInstance = 0;

S::S() { atexit(&CleanUp); }

S::CleanUp() { delete MInstance; MInstance = 0; } // Note the = 0 bit!!!

Во-первых, давайте узнаем больше о atexit . Подпись int atexit (void (* function) (void)); , т.е. она принимает указатель на функцию, которая ничего не принимает в качестве аргумента и ничего не возвращает.

Во-вторых, как это работает? Точно так же, как и в предыдущем варианте использования: при инициализации он создает стек указателей на функцию для вызова, а при уничтожении он очищает стек по одному элементу за раз. Таким образом, по сути, функции вызываются по принципу «последним вошел - первым ушел».

Что здесь происходит тогда?

• Построение при первом доступе (инициализация в порядке), я регистрирую метод CleanUp для времени выхода

• Время выхода: метод CleanUp называется. Он уничтожает объект (таким образом, мы можем эффективно выполнять работу в деструкторе) и сбрасывать указатель на 0 , чтобы сигнализировать об этом.

Что произойдет, если (как в примере с A , B и C ) я вызову экземпляр уже уничтоженного объекта? Что ж, в этом случае, поскольку я вернул указатель на 0 , я перестрою временный синглтон, и цикл начнется заново. Но долго это не протянет, так как я удаляю свой стек.

Александреску назвал его Phoenix Singleton , поскольку он воскресает из пепла, если он нужен после того, как был уничтожен.

Другой альтернативой является наличие статического флага и установка для него значения уничтожено во время очистки и информирование пользователя о том, что он не получил экземпляр синглтона, например, путем возврата нулевого указателя. Единственная проблема, с которой я сталкиваюсь с возвратом указателя (или ссылки), заключается в том, что вам лучше надеяться, что никто не будет настолько глуп, чтобы вызвать для него delete : /

4. Паттерн моноид

Поскольку мы говорим о Синглтоне , я думаю, что пришло время представить паттерн Моноид . По сути, это можно рассматривать как вырожденный случай паттерна Flyweight или использование Proxy вместо Singleton .

Шаблон Моноид прост: все экземпляры класса имеют общее состояние.

Я воспользуюсь возможностью, чтобы разоблачить реализацию не-Phoenix :)

class Monoid
{
public:
  void foo() { if (State* i = Instance()) i->foo(); }
  void bar() { if (State* i = Instance()) i->bar(); }

private:
  struct State {};

  static State* Instance();
  static void CleanUp();

  static bool MDestroyed;
  static State* MInstance;
};

// .cpp
bool Monoid::MDestroyed = false;
State* Monoid::MInstance = 0;

State* Monoid::Instance()
{
  if (!MDestroyed && !MInstance)
  {
    MInstance = new State();
    atexit(&CleanUp);
  }
  return MInstance;
}

void Monoid::CleanUp()
{
  delete MInstance;
  MInstance = 0;
  MDestroyed = true;
}

Какая польза? Он скрывает тот факт, что состояние является общим, он скрывает синглтон .

• Если вам когда-нибудь понадобится иметь 2 разных состояния, возможно, вам удастся сделать это, не изменяя каждую строку кода, в котором оно использовалось (замена Singleton вызовом Factory , например)
• Nodoby вызовет delete в экземпляре вашего синглтона, чтобы вы действительно управляли состоянием и предотвращали несчастные случаи ...в любом случае ты ничего не сможешь сделать против злоумышленников!
• Вы контролируете доступ к синглтону, поэтому в случае его вызова после его уничтожения вы можете обработать его правильно (ничего не делать, регистрировать и т. Д.)

5. Последнее слово

Каким бы полным это ни казалось, я хотел бы отметить, что я с радостью просмотрел любые проблемы с многопоточностью ... прочтите «Современный C ++» Александреску, чтобы узнать больше!