c++ - 设计着色器类

Question

自从我开始学习 OpenGL 以来，我想我还不如编写一个小型 C++ 框架(为我自己)来避免过度使用 C-ish 代码显然造成的恶心。 :) 由于我打算坚持使用 Qt，因此该框架使用了一些 Qt 类。

我真正需要的第一件事是使用着色器和程序的简单方法。这是我对着色器类的想法。

class Shader
{
public:
    //create a shader with no source code 
    explicit Shader(GLenum shaderType);
    //create a shader with source code and compile it
    Shader(GLenum shaderType, const QString& sourceCode);
    //create a shader from source file and compile it
    Shader(GLenum shaderType, QFile& sourceFile);
    ~Shader();

    //change the source code and recompile
    void Source(QFile& sourceFile);
    void Source(const QString& sourceCode);

    GLuint get() const; //get the handle

private:
    //common part for creation in different constructors
    void createShader(GLenum shaderType); 
    //compile
    void compile();

private:
    GLuint handle;
};

不同功能的作用一定很明显。每个都调用相关的 OpenGL 例程，检查错误并在出现任何故障时抛出异常。构造函数调用 glCreateShader。现在是棘手的部分。析构函数需要调用 glDeleteShader(handle); 但在这种情况下我有一个进退两难的问题:

选项 1: 禁用分配和复制。这有避免引用计数的好处，也有被迫使用 shared_pointers 将它们放在 vector 中并在一般情况下传递的缺点。

选项 2:启用引用计数。这具有启用复制的明显优势，因此可以存储在容器中(稍后我需要将一系列着色器传递给程序)。缺点如下:

Shader s1(GL_VERTEX_SHADER, QFile("MyVertexShader.vp"));
Shader s2(s1);
s2.Source(QFile("MyOtherVertexShader.vp"));

如您所见，我通过 s2 更改了 s1 的源代码，因为它们共享相同的内部着色器句柄。老实说，我看不出这里有什么大问题。我写了这个类，所以我知道它的复制语义是这样的，我对此很满意。问题是我不确定这种设计是否可以接受。所有这一切都可以通过 Option1 + 共享指针来实现，唯一的区别是我不想每次创建着色器时都有一个共享指针(不是出于性能原因 - 只是为了语法方便)。

Q1:请对选项和整个想法发表评论(可选)。¹
Q2:如果我选择选项 2，我是否必须自己实现它，或者在 boost 或 Qt 中有一个现成的类，我可以从中派生或拥有它的成员，我将获得免费引用数数？
问题 3:您是否同意将 Shader 设为抽象类并拥有三个派生类 VertexShader、FragmentShader 和 GeometryShader 会矫枉过正吗？

¹ _{如果你应该向我推荐一个现有的 C++ OpenGL 框架，那很好(因为我还没有真正找到一个)但那真的应该作为旁注而不是回答我的问题。另请注意，我在文档的某处看到了一个 QGLShader 类，但它显然不存在于我的 Qt 版本中，我有理由立即避免升级。}

更新

感谢您的回答。我最终决定通过删除源函数使我的着色器类不可变。着色器在创建时被编译并且没有非常量成员函数。因此，一个简单的引用计数可以立即解决我所有的问题。

Answer 1

我说的是使用选项 1:它可以做选项 2 可以做的所有事情(通过智能指针)，而选项 2 让您支付间接成本，即使您不需要它。最重要的是，它可以说更容易编写。

同样，我曾经考虑过在包装 C API 时使用 handle-body/PIMPL，以允许从函数返回对象(不能保证 C 句柄类型可复制，因此间接访问是必要的)。我决定反对它因为 std::unique_ptr<T>执行不可移动 -> 可移动转换(就像 shared_ptr<T> 使 T 可复制)。从那时起，我将我的类设计为具有“最严格”的移动/复制语义。

然而，当谈到句法噪音时，你确实有道理! Boost.Phoenix 和 lambda 之类的东西往往会有所帮助。如果/当它们不是一个选项时，我会说写一个单独的 shared_shader或任何包装器(包装器包装器？)是有意义的，至少对于库级代码(我相信这里是这种情况)。我不知道有什么实用程序可以帮助处理繁琐的转发函数。

我对着色器也不太了解，所以我不确定我能否回答您的最后一个问题。我认为如果不同着色器的数量经常变化，那么创建一个类层次结构是有意义的。我不认为是这样；我还认为，即使是这种情况，因为您级别的实现正在包装一个预先存在的 API，如果/当添加了新的着色器时，重新访问代码以转发到该 API 也不会太麻烦。

---

既然你要的是 Phoenix niceness 的例子。

假设我不需要取消引用，我想做什么:

std::transform(begin, end, functor);

相反:

std::for_each(begin, end, *arg1 = ref(functor)(*arg1));

仍然可以使用 std::transform (为清楚起见，希望)使用一些 Phoenix 设施(construct IIRC)，但这会花费分配。