Перейти к содержимому

Статические участники, Singletons & PIMPL

Исследуйте статические элементы, шаблон Meyers Singleton, шаблон Factory и идиому PIMPL для стабильности ABI и изоляции во времени компиляции.

За пределами основных классов

Как только вы привыкнете к классам, конструкторам и наследству, вам понадобятся шаблоны проектирования — проверенные решения повторяющихся проблем. Этот урок охватывает три важных шаблона: Singleton (контролируемый глобальный доступ), Factory (разъединенное создание объектов) и PIMPL (компиляционный брандмауэр и стабильность ABI). Мы также возвращаемся к статическим членам и их современной встроенной инициализации C++17.

Статические члены и встроенная статика (C++17)

Статические переменные делятся на все экземпляры класса — существует ровно одна копия независимо от того, сколько объектов существует. До C++17 статические элементы должны были быть определены в файле .cpp. C++17 inline static позволяет определять непосредственно в заголовке.

static_members.cpp
#include <iostream>
#include <string>
#include <vector>

class Logger {
    // C++17: inline static — no separate .cpp definition needed
    inline static std::vector<std::string> messages_;
    inline static int error_count_ = 0;

public:
    // Static member function — no 'this' pointer, can only
    // access static members
    static void log(const std::string& msg) {
        messages_.push_back(msg);
    }

    static void error(const std::string& msg) {
        messages_.push_back("[ERROR] " + msg);
        ++error_count_;
    }

    static void dump() {
        for (const auto& m : messages_) {
            std::cout << m << '\n';
        }
        std::cout << "Total errors: " << error_count_ << '\n';
    }

    static int error_count() { return error_count_; }
};

int main() {
    Logger::log("Application started");
    Logger::error("File not found");
    Logger::log("Retrying...");
    Logger::error("Permission denied");
    Logger::dump();
    return 0;
}

Мейерс Синглтон (Thread-Safe)

Meyers Singleton использует функционально-локальную статическую переменную, которую гарантирует C++11. Это самый простой и безопасный способ реализации синглтона в современном C++.

singleton.cpp
#include <iostream>
#include <string>

class AppConfig {
public:
    // Delete copy and move to prevent duplication
    AppConfig(const AppConfig&) = delete;
    AppConfig& operator=(const AppConfig&) = delete;

    // Meyers Singleton: function-local static
    static AppConfig& instance() {
        static AppConfig config;  // thread-safe since C++11
        return config;
    }

    void set_debug(bool d) { debug_ = d; }
    bool debug() const { return debug_; }

    void set_app_name(const std::string& name) { app_name_ = name; }
    const std::string& app_name() const { return app_name_; }

private:
    // Private constructor — only instance() can create
    AppConfig() : debug_{false}, app_name_{"MyApp"} {}

    bool debug_;
    std::string app_name_;
};

int main() {
    auto& config = AppConfig::instance();
    config.set_app_name("SuperApp");
    config.set_debug(true);

    // Same instance everywhere
    std::cout << AppConfig::instance().app_name() << '\n';
    std::cout << std::boolalpha
              << AppConfig::instance().debug() << '\n';
    return 0;
}

Фабричная модель

Фабрика отделяет создание объекта от использования. Звонящие указывают, что они хотят (например, тип формы), и завод решает, какой конкретный класс создать. Это чище, чем цепочка утверждений if/else или switch на каждом сайте создания.

factory.cpp
#include <iostream>
#include <memory>
#include <string>
#include <stdexcept>

class Shape {
public:
    virtual ~Shape() = default;
    virtual double area() const = 0;
    virtual std::string name() const = 0;
};

class Circle : public Shape {
    double r_;
public:
    explicit Circle(double r) : r_{r} {}
    double area() const override { return 3.14159265 * r_ * r_; }
    std::string name() const override { return "Circle"; }
};

class Square : public Shape {
    double side_;
public:
    explicit Square(double s) : side_{s} {}
    double area() const override { return side_ * side_; }
    std::string name() const override { return "Square"; }
};

// Factory function — callers don't need to know concrete types
[[nodiscard]]
std::unique_ptr<Shape> make_shape(const std::string& type, double size) {
    if (type == "circle") return std::make_unique<Circle>(size);
    if (type == "square") return std::make_unique<Square>(size);
    throw std::invalid_argument("Unknown shape: " + type);
}

int main() {
    auto s1 = make_shape("circle", 5.0);
    auto s2 = make_shape("square", 4.0);

    std::cout << s1->name() << ": " << s1->area() << '\n';
    std::cout << s2->name() << ": " << s2->area() << '\n';
    return 0;
}

Идиома PIMPL (Pointer to Implementation)

Идиома PIMPL (Pointer to Implementation) скрывает детали реализации за непрозрачным указателем. Преимущества: (1) изменение реализации не требует перекомпиляции клиентов, (2) в заголовке не появляются частные участники (стабильность ABI), (3) более быстрая компиляция, поскольку заголовки реализации нужны только в файле .cpp.

pimpl.cpp
// ========== widget.hpp ==========
#include <memory>
#include <string>

class Widget {
public:
    Widget(const std::string& name, int value);
    ~Widget();  // must be declared; defined in .cpp

    // Move operations — defined in .cpp where Impl is complete
    Widget(Widget&&) noexcept;
    Widget& operator=(Widget&&) noexcept;

    // No copy (or implement deep copy in .cpp)
    Widget(const Widget&) = delete;
    Widget& operator=(const Widget&) = delete;

    void do_work() const;
    std::string name() const;

private:
    struct Impl;  // forward declaration only!
    std::unique_ptr<Impl> pimpl_;  // opaque pointer
};

// ========== widget.cpp ==========
// #include "widget.hpp"
#include <iostream>

struct Widget::Impl {
    std::string name;
    int value;
    // Any complex private members go here
    // Changes here do NOT affect the header!
};

Widget::Widget(const std::string& name, int value)
    : pimpl_{std::make_unique<Impl>(Impl{name, value})} {}

Widget::~Widget() = default;  // Impl is complete here
Widget::Widget(Widget&&) noexcept = default;
Widget& Widget::operator=(Widget&&) noexcept = default;

void Widget::do_work() const {
    std::cout << "Working on: " << pimpl_->name
              << " (value=" << pimpl_->value << ")\n";
}

std::string Widget::name() const { return pimpl_->name; }

int main() {
    Widget w{"Engine", 42};
    w.do_work();
    std::cout << w.name() << '\n';
    return 0;
}
Подводный камень

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

Лучшая практика

Используйте PIMPL для библиотечных интерфейсов, где важна стабильность ABI — изменение частных членов без PIMPL изменяет макет класса, нарушая бинарную совместимость. PIMPL также значительно сокращает время компиляции в крупных проектах, скрывая заголовки реализации. Стоимость - одно дополнительное распределение кучи и одно опосредование указателя за вызов. Для критически важного для производительности кода внутреннего цикла PIMPL может быть неуместным.

Ключевые выводы
  • C++177 inline static позволяет определять статические члены непосредственно в заголовке класса
  • Meyers Singleton использует функционально-локальную статику — безопасную для потоков с C++11
  • Фабрика отделяет создание объекта от использования, улучшая расширяемость
  • PIMPL скрывает детали реализации, обеспечивая стабильность ABI и более быструю компиляцию.
  • Синглтоны — это замаскированное глобальное государство — используйте их экономно и предпочитайте инъекции зависимости.
  • [[nodiscard]] на заводских функциях не позволяет абонентам случайно игнорировать созданный объект

Тест — проверьте свои знания

(15 XP)

1. Почему нить Meyers Singleton безопасна в C++11 и более поздних версиях?

2. Каковы основные преимущества идиомы PIMPL?

3. Почему в файле .cpp должен быть определен PIMPL-деструктор, а не заголовок?