Каковы причины предпочтения локальных статических объектов Singleton или области действия над другими?

Question

Обе Маршалла Клайна "C ++ FAQ Lite" и Скотта Мейерса "Эффективный C ++" предлагают использовать функции, возвращающие локальные статические объекты, чтобы избежать возможных проблем с порядком инициализации нелокального статического объекта.

Короче говоря (из "Effective C ++", 3-е издание Скотта Мейерса):

FileSystem& tfs()
{
  static FileSystem fs;
  return fs;
}

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

Теперь, в ситуации, когда достаточно одного экземпляра класса управления ресурсами T, с какими причинами вы предпочитаете класс Singleton или этот локальный статический подход друг другу? Нет необходимости строго ограничивать использование класса T одним экземпляром, хотя нашему приложению не требуется более одного.

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

Answer 1

Вы можете использовать оба:

class Singleton {

   public:

      static Singleton & Instance() {
          static Singleton s;
          return s;
      }

   private:

       Singleton() {}
};

Теперь единственный способ создания Singleton - это использование функции Instance (поскольку конструктор является приватным), и поэтому вы можете гарантировать, что существует только один Singleton. Если вы хотите использовать подход свободных функций, описанный в вашем вопросе, вы можете рассмотреть возможность сделать функцию другом класса Singleton, сохранив при этом закрытый конструктор.

Обратите внимание, что эта конструкция (как и все конструкции, включающие статические переменные) не является поточно-ориентированной. Если безопасность потока является проблемой, вам нужно рассмотреть что-то вроде шаблона двойной проверки блокировки при доступе к статической переменной Singleton.

Answer 2

Singleton используется, когда вы не можете иметь более одного объекта, скажем, класс CEO - очевидно, два или более CEO s разрушат вашу компанию;) Для Singleton вы не можете создать более одного объект по определению

• частный ctor
• статический аксессор.

Однако локальные объекты области действия - это совсем другое животное. Эта идиома не исключает возможности наличия других подобных объектов. Это часто встречается в случае классов Logger, где вы можете создавать свои собственные объекты Logger, а средство записи библиотеки также предоставляет вам функцию DefaultLogger() для быстрой и уродливой регистрации, которая просто оборачивает объект static Logger.

Обратите внимание, что некоторые реализации средства доступа к объекту Singleton могут использовать переменную области действия функции idiom.