基于C++与GLFW的RAII架构设计问题求助

这是个非常典型的资源生命周期管理问题，尤其是针对GLFW这种绑定全局状态的库——我之前在封装GLFW引擎的时候也踩过几乎一模一样的坑，分享几个我验证过的、能真正做到“几乎无法误用”的优雅方案：

最优方案：强制单例化GLFW上下文 + 窗口持有强引用 #

GLFW本身的API设计就是全局状态绑定的：多次调用glfwInit()是未定义行为，且glfwTerminate()必须在所有窗口销毁后调用。既然底层有这样的约束，我们的封装就应该强制用户遵守这个约束，而不是靠文档提醒。

具体实现思路：

1. 将glfw_context的构造函数设为私有，通过静态工厂方法创建唯一实例，确保全局只有一个上下文存在
2. 让glfw_window的构造函数必须接收std::shared_ptr<glfw_context>，并将其保存为成员变量
3. 利用shared_ptr的引用计数机制，保证上下文的生命周期自动覆盖所有窗口的生命周期

代码示例 #

#include <GLFW/glfw3.h>
#include <memory>
#include <stdexcept>

class glfw_context {
private:
    // 私有构造/析构，禁止外部直接创建
    glfw_context() {
        if (!glfwInit()) {
            throw std::runtime_error("Failed to initialize GLFW");
        }
    }

    ~glfw_context() {
        glfwTerminate();
    }

    // 彻底禁止拷贝与移动
    glfw_context(const glfw_context&) = delete;
    glfw_context& operator=(const glfw_context&) = delete;
    glfw_context(glfw_context&&) = delete;
    glfw_context& operator=(glfw_context&&) = delete;

    // 辅助类，让make_shared可以访问私有构造
    struct enable_make_shared : public glfw_context {};

public:
    // 唯一的实例创建入口
    static std::shared_ptr<glfw_context> create() {
        return std::make_shared<enable_make_shared>();
    }
};

class glfw_window {
private:
    std::shared_ptr<glfw_context> ctx_; // 持有上下文的强引用，保证其存活
    GLFWwindow* window_ = nullptr;

public:
    // 必须传入上下文的强引用，无法绕过
    glfw_window(std::shared_ptr<glfw_context> ctx, int width, int height, const char* title)
        : ctx_(std::move(ctx)) {
        window_ = glfwCreateWindow(width, height, title, nullptr, nullptr);
        if (!window_) {
            throw std::runtime_error("Failed to create GLFW window");
        }
    }

    // 支持移动语义，符合RAII
    glfw_window(glfw_window&& other) noexcept
        : ctx_(std::move(other.ctx_)), window_(other.window_) {
        other.window_ = nullptr;
    }

    glfw_window& operator=(glfw_window&& other) noexcept {
        if (this != &other) {
            if (window_) glfwDestroyWindow(window_);
            ctx_ = std::move(other.ctx_);
            window_ = other.window_;
            other.window_ = nullptr;
        }
        return *this;
    }

    // 禁止拷贝，避免窗口资源重复释放
    glfw_window(const glfw_window&) = delete;
    glfw_window& operator=(const glfw_window&) = delete;

    ~glfw_window() {
        if (window_) glfwDestroyWindow(window_);
    }

    // 示例：窗口操作方法
    void make_current() {
        glfwMakeContextCurrent(window_);
    }
};

这个方案的优势 #

• 完全防误用：用户无法创建多个上下文实例，也无法写出上下文生命周期短于窗口的代码（因为窗口持有强引用，只要有窗口存活，上下文就不会被销毁）
• 异常安全：构造失败时抛出异常，shared_ptr会自动清理已创建的资源，不会留下泄漏的GLFW状态
• 符合RAII：所有资源的创建/销毁都由对象的构造/析构自动处理，无需手动调用初始化/终止函数

为什么单例在这里不是“坏味道”？ #

很多人会反感单例，但这里的单例是对底层API约束的合理封装：GLFW本身不支持多个独立的上下文环境，强制单例只是把底层的隐性规则变成了代码层面的强制约束，避免用户触发未定义行为，这是封装的核心价值之一。

备选方案：全局计数器跟踪上下文状态（仅适合信任用户的场景） #

如果你确实需要支持多上下文（比如特殊的多线程场景，GLFW允许每个线程一个上下文），可以用全局计数器跟踪上下文的激活状态：

• glfw_context构造时，检查全局计数器，若为0则调用glfwInit()，计数器加1
• glfw_context析构时，计数器减1，若为0则调用glfwTerminate()
• glfw_window构造时，检查全局计数器是否大于0，否则抛出异常

但这个方案无法阻止用户写出上下文先于窗口销毁的代码（比如你的示例代码），只能在运行时抛出异常，无法做到编译期防误用，所以仅适合信任用户不会违反生命周期规则的场景。

内容的提问来源于stack exchange，提问作者cubber