如何允许 std::unique_ptr 访问 class 的私有析构函数或使用私有析构函数实现 C++ 工厂 class？

Question

我已经深入研究使用 SDL、OpenGL 和 C++ 开发游戏，并且正在寻找方法来优化游戏在 GLSL 着色器之间为许多不同类型的对象切换的方式。这更像是一个 C++ 问题，而不是一个 OpenGL 问题。但是，我仍然想提供尽可能多的上下文，因为我觉得需要一些理由来说明为什么我需要的拟议着色器 class 需要按原样创建/删除。

前四个部分是我的理由、旅程和尝试，但仅最后一节就可以回答我的问题，我故意把它写得有点冗长。

着色器的必要性class:

我在网上看到过很多 OpenGL 着色器的实现，它们都是在游戏过程中创建游戏对象时在同一个函数中创建、编译和删除的。在我的游戏的特定部分，这已被证明效率低下且速度太慢。因此，我需要一个系统，它可以在加载期间创建和编译着色器，然后在游戏期间间歇性地 uses/swaps 在稍后删除之前在它们之间进行 uses/swaps。

这导致了管理 OpenGL 着色器的 class(Shader) 的创建。 class 的每个实例都应该管理一个唯一的 OpenGL 着色器，并包含一些围绕着色器类型的复杂行为，从哪里加载它，在哪里使用它，它采用的统一变量等等。

话虽如此，这个class最重要的作用是存储GLuint变量id，即return由glCreateShader()编辑而来，并使用此 id 管理与 OpenGL 着色器相关的所有 OpenGL 调用。我知道鉴于 OpenGL 的全局性质，这实际上是徒劳的（因为程序中的任何地方在技术上都可以用匹配的 id 调用 glDeleteShader() 并打破 class），但是为了有意将所有 OpenGL 调用封装到整个代码库中非常特定的区域，此系统将大幅降低代码复杂性。

问题从哪里开始...

管理此 GLuint id 的最“自动”方式是在对象构造时调用 glCreateShader() 并在对象销毁时调用 glDeleteShader()。这保证（在 OpenGL 限制内）OpenGL 着色器将在 C++ 着色器对象的整个生命周期内存在，并且无需调用某些 void createShader() 和 deleteShader() 函数。

这一切都很好，但是当考虑复制此对象时会发生什么情况时很快就会出现问题。如果这个对象的副本被破坏了怎么办？这意味着 glDeleteShader() 将被调用并有效地破坏着色器对象的所有副本。

在着色器向量中意外调用 std::vector::push_back() 等简单错误怎么办？各种 std::vector 方法可以调用其类型的构造函数/复制构造函数/析构函数，这可能会导致与上述相同的问题。

好吧...我们创建一些 void createShader() 和 deleteShader() 方法怎么样，即使它很乱？不幸的是，这只是推迟了上述问题，因为再次任何修改 OpenGL 着色器的调用将不同步/彻底破坏具有相同 id 的着色器 class 的所有副本].为了简单起见，我在此示例中将 OpenGL 调用限制为 glCreateShader() 和 glDeleteShader()，但是我应该注意 class 中还有许多其他 OpenGL 调用，这将使创建各种instance/static 跟踪实例副本的变量太复杂了，无法证明这样做是合理的。

在进入下面的 class 设计之前，我想说的最后一点是，对于像原始 C++、OpenGL 和 SDL 游戏这样大的项目，如果有任何潜在的 OpenGL 错误，我更愿意make 生成编译器错误与更难追踪的图形问题。这可以反映在下面的 class 设计中。

第一个版本`Shader` class:

基于以上原因，我选择：

构造函数private.
提供一个 public static create 函数，该函数 return 是一个指向新 Shader 对象的指针，而不是构造函数。
创建复制构造函数private。
制作 operator= private（尽管这可能不是必需的）。
将析构函数设为私有。
在构造函数中调用 glCreateShader()，在析构函数中调用 glDeleteShader()，以使 OpenGL 着色器在该对象的生命周期内存在。
由于 create 函数调用 new 关键字（和 return 指向它的指针），外部调用 Shader::create() 的地方必须调用delete 手动（稍后详细介绍）。

据我了解，前两个要点使用工厂模式，如果尝试创建 class 的非指针类型，将产生编译器错误。第三个、第四个和第五个要点防止对象被复制。第七个要点确保 OpenGL 着色器将在 C++ 着色器对象的相同生命周期内存在。

智能指针和主要问题：

我唯一不喜欢的是 new/delete 调用。鉴于 class 试图实现的封装，它们还使对象的析构函数中的 glDeleteShader() 调用感觉不合适。鉴于此，我选择：

将 create 函数更改为 return Shader 类型的 std::unique_ptr 而不是 Shader 指针。

create 函数看起来像这样：

std::unique_ptr<Shader> Shader::create() {
    return std::make_unique<Shader>();
}

但是后来又出现了新的问题... std::make_unique不幸的是要求constructor是public，这干扰了前面描述的必需品部分。幸运的是，我找到了解决方案，将其更改为：

std::unique_ptr<Shader> Shader::create() {
    return std::unique_ptr<Shader>(new Shader());
}

但是...现在 std::unique_ptr 要求 析构函数 是 public！这是...更好但不幸的是，这意味着可以在 class 外部手动调用析构函数，这反过来意味着可以从 class 外部调用 glDeleteShader() 函数。

Shader* p = Shader::create();
p->~Shader(); // Even though it would be hard to do this intentionally, I don't want to be able to do this.
delete p;

决赛class:

为了简单起见，我删除了大部分实例变量、function/constructor 参数和其他属性，但这是最终提议的 class（大部分）看起来像：

class GLSLShader {

public:
    ~GLSLShader() { // OpenGL delete calls for id }; // want to make this private.

    static std::unique_ptr<GLSLShader> create() { return std::unique_ptr<GLSLShader>(new GLSLShader()); };

private:
    GLSLShader() { // OpenGL create calls for id };

    GLSLShader(const GLSLShader& glslShader);
    GLSLShader& operator=(const GLSLShader&);

    GLuint id;

};

除了析构函数是 public，我对 class 中的所有内容都很满意。我已经对这个设计进行了测试，性能提升非常明显。尽管我无法想象我会不小心手动调用 Shader 对象上的析构函数，但我不喜欢它 public 公开。我也觉得我可能会不小心漏掉一些东西，比如第二部分的 std::vector::push_back 考虑。

我找到了解决此问题的两种可能方法。我想要一些关于这些或其他解决方案的建议。

使 std::unique_ptr 或 std::make_unique 成为 Shader class 的 friend。我一直在阅读诸如之类的线程，但这是为了使构造函数可访问，而不是析构函数。我也不太明白将 std::unique_ptr 或 std::make_unique 设为 friend（该主题的最佳答案 + 评论）所需的缺点/额外注意事项？
根本不使用智能指针。有没有办法让我的 static create() 函数 return 成为一个原始指针（使用 new 关键字），在 class / 当 Shader 超出范围并调用析构函数？

非常感谢您抽出宝贵时间。

Answer 1

自己实现一个删除器，让删除器成为您class的朋友。然后像这样编辑您的声明：

static std::unique_ptr<GLSLShader, your_deleter> create();

Answer 2

这是一个上下文挑战。

您正在解决错误的问题。

GLuint id, would be to invoke glCreateShader() on the object's construction and glDeleteShader()

解决这里的问题。

零法则 是让资源包装器管理生命周期，而不是在业务逻辑类型中这样做。我们可以围绕 GLuint 编写一个包装器，它知道如何清理自身并且只能移动，通过劫持 std::unique_ptr 来存储整数而不是指针来防止双重破坏。

我们开始：

// "pointers" in unique ptrs must be comparable to nullptr.
// So, let us make an integer qualify:
template<class Int>
struct nullable{
  Int val=0;
  nullable()=default;
  nullable(Int v):val(v){}
  friend bool operator==(std::nullptr_t, nullable const& self){return !static_cast<bool>(self);}
  friend bool operator!=(std::nullptr_t, nullable const& self){return static_cast<bool>(self);}
  friend bool operator==(nullable const& self, std::nullptr_t){return !static_cast<bool>(self);}
  friend bool operator!=(nullable const& self, std::nullptr_t){return static_cast<bool>(self);}
  operator Int()const{return val;}
};

// This both statelessly stores the deleter, and
// tells the unique ptr to use a nullable<Int> instead of an Int*:
template<class Int, void(*deleter)(Int)>
struct IntDeleter{
  using pointer=nullable<Int>;
  void operator()(pointer p)const{
    deleter(p);
  }
};

// Unique ptr's core functionality is cleanup on destruction
// You can change what it uses for a pointer. 
template<class Int, void(*deleter)(Int)>
using IntResource=std::unique_ptr<Int, IntDeleter<Int,deleter>>;

// Here we statelessly remember how to destroy this particular
// kind of GLuint, and make it an RAII type with move support:
using GLShaderResource=IntResource<GLuint,glDeleteShader>;

现在该类型知道它是一个着色器并将其自身清理为非空。

GLShaderResource id(glCreateShader());
SomeGLFunction(id.get());

对于任何打字错误表示歉意。

你 class 中的东西，复制 ctors 被阻止，移动 ctors 做正确的事情，dtors 自动清理，等等

struct GLSLShader {
  // public!
  ~GLSLShader() = default;
  GLSLShader() { // OpenGL create calls for id };
private: // does this really need to be private?
  GLShaderResource id;
};

简单多了。

std::vector<GLSLShader> v;

这很管用。我们的 GLShaderResource 是半正则的（仅移动正则类型，不支持排序），vector 对此很满意。规则 0 意味着拥有它的 GLSLShader 也是半规则的并且支持 RAII —— 资源分配是初始化 —— 这反过来意味着它在存储在 std 容器中时会自行清理.

“常规”类型意味着它“表现得像 int”——就像原型值类型。当您使用常规或半常规类型时，C++ 的标准库和大部分 C++ 都喜欢它。

请注意，这基本上是零开销； sizeof(GLShaderResource) 与 GLuint 相同，堆上没有任何内容。我们有一堆编译时类型的机器包装一个简单的 32 位整数；编译时类型的机器生成 code，但不会使数据比 32 位更复杂。

Live example.

开销包括：

一些调用约定使得传递 struct 仅包装 int 与传递 int.
不同
在销毁时，我们检查其中的每一个，看它是否是 0 来决定我们是否要调用 glDeleteShader；编译器有时可以证明某些东西保证为零并跳过该检查。但它不会告诉你它是否确实成功了。（OTOH，众所周知，人类在证明他们跟踪所有资源方面表现不佳，因此一些运行时检查并不是最糟糕的事情）。
如果您正在执行完全未优化的构建，则在调用 OpenGL 函数时会有一些额外的指令。但是在编译器的任何非零级别 inlineing 之后，它们都会消失。
类型在某些方面（可复制、可破坏、可构造）不是“微不足道的”（C++ 标准中的一个术语），这使得像 memset 这样的事情在以下情况下是非法的C++标准；您不能以一些低级别的方式将其视为原始内存。

有问题！

许多 OpenGL 实现都有指向 glDeleteShader/glCreateShader 等的指针，上面依赖于它们是实际函数，而不是指针或宏或其他任何东西。

有两个简单的解决方法。第一个是将 & 添加到上面的 deleter 参数（两个位置）。这有一个问题，它只在它们现在实际上是指针时才有效，而不是当它们是实际函数时。

编写适用于这两种情况的代码有点棘手，但我认为几乎每个 GL 实现都使用函数指针，所以你应该很好，除非你想制作一个“库质量”的实现。在这种情况下，您可以编写一些帮助程序类型来创建 constexpr 函数指针，这些函数指针按名称调用（或不调用）函数指针。

最后，显然有些析构函数需要额外的参数。这是草图。

using GLuint=std::uint32_t;

GLuint glCreateShaderImpl() { return 7; }
auto glCreateShader = glCreateShaderImpl;
void glDeleteShaderImpl(GLuint x) { std::cout << x << " deleted\n"; }
auto glDeleteShader = glDeleteShaderImpl;

std::pair<GLuint, GLuint> glCreateTextureWrapper() { return {7,1024}; }

void glDeleteTextureImpl(GLuint x, GLuint size) { std::cout << x << " deleted size [" << size << "]\n"; }
auto glDeleteTexture = glDeleteTextureImpl;

template<class Int>
struct nullable{
  Int val=0;
  nullable()=default;
  nullable(Int v):val(v){}
  nullable(std::nullptr_t){}
  friend bool operator==(std::nullptr_t, nullable const& self){return !static_cast<bool>(self);}
  friend bool operator!=(std::nullptr_t, nullable const& self){return static_cast<bool>(self);}
  friend bool operator==(nullable const& self, std::nullptr_t){return !static_cast<bool>(self);}
  friend bool operator!=(nullable const& self, std::nullptr_t){return static_cast<bool>(self);}
  operator Int()const{return val;}
};

template<class Int, auto& deleter>
struct IntDeleter;

template<class Int, class...Args, void(*&deleter)(Int, Args...)>
struct IntDeleter<Int, deleter>:
  std::tuple<std::decay_t<Args>...>
{
  using base = std::tuple<std::decay_t<Args>...>;
  using base::base;
  using pointer=nullable<Int>;
  void operator()(pointer p)const{
    std::apply([&p](std::decay_t<Args> const&...args)->void{
        deleter(p, args...);
    }, static_cast<base const&>(*this));
  }
};

template<class Int, void(*&deleter)(Int)>
using IntResource=std::unique_ptr<Int, IntDeleter<Int,deleter>>;

using GLShaderResource=IntResource<GLuint,glDeleteShader>;

using GLTextureResource=std::unique_ptr<GLuint,IntDeleter<GLuint, glDeleteTexture>>;

int main() {
    auto res = GLShaderResource(glCreateShader());
    std::cout << res.get() << "\n";
    auto tex = std::make_from_tuple<GLTextureResource>(glCreateTextureWrapper());
    std::cout << tex.get() << "\n";
}

如何允许 std::unique_ptr 访问 class 的私有析构函数或使用私有析构函数实现 C++ 工厂 class？

How to allow a std::unique_ptr to access a class's private destructor or implement a C++ factory class with a private destructor?

c++

destructor

smart-pointers

friend-class

着色器的必要性class:

问题从哪里开始...

第一个版本`Shader` class:

智能指针和主要问题：

决赛class:

您正在解决错误的问题。

有问题！

如何允许 std::unique_ptr 访问 class 的私有析构函数或使用私有析构函数实现 C++ 工厂 class？

How to allow a std::unique_ptr to access a class's private destructor or implement a C++ factory class with a private destructor?

c++

destructor

smart-pointers

friend-class

着色器的必要性class:

问题从哪里开始...

第一个版本Shader class:

智能指针和主要问题：

决赛class:

您正在解决错误的问题。

有问题！

第一个版本`Shader` class: