Статические участники, Singletons & PIMPL
Исследуйте статические элементы, шаблон Meyers Singleton, шаблон Factory и идиому PIMPL для стабильности ABI и изоляции во времени компиляции.
За пределами основных классов
Как только вы привыкнете к классам, конструкторам и наследству, вам понадобятся шаблоны проектирования — проверенные решения повторяющихся проблем. Этот урок охватывает три важных шаблона: Singleton (контролируемый глобальный доступ), Factory (разъединенное создание объектов) и PIMPL (компиляционный брандмауэр и стабильность ABI). Мы также возвращаемся к статическим членам и их современной встроенной инициализации C++17.
Статические члены и встроенная статика (C++17)
Статические переменные делятся на все экземпляры класса — существует ровно одна копия независимо от того, сколько объектов существует. До C++17 статические элементы должны были быть определены в файле .cpp. C++17 inline static позволяет определять непосредственно в заголовке.
#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++.
#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 на каждом сайте создания.
#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.
// ========== 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-деструктор, а не заголовок?