命名空间 gl 中的 OpenGL 函数有什么缺点？答案

【问题标题】：what would be the disadvantage for OpenGL functions in namespace gl?命名空间 gl 中的 OpenGL 函数有什么缺点？
【发布时间】：2016-08-26 15:11:27
【问题描述】：

我目前正在使用glLoadGen来加载OpenGL函数，

有一个选项，比如将所有函数指针放在namespace gl 这样我就可以像gl::CreateShader( ... )一样使用它们了

该功能有什么缺点？？

它不会用 gl** 函数或宏污染全局命名空间；但恐怕有一些潜在的缺点......

【问题讨论】：

This question 是相关的。
我不明白你为什么要使用这个选项。您每次都需要输入额外的::，您将无法直接从其他来源复制粘贴 GL 代码。你说这个选项很好，因为它不会污染全局命名空间，但如果所有名称都有适当的前缀，污染不是问题。
@CoryKramer 相关，但不密切，因为这不是 glLoadGen 所做的（取决于选项）。
@HolyBlackCat: "你不能直接从其他来源复制粘贴 GL 代码" 这听起来是一个很好的理由使用它。复制粘贴编码是坏事。
@NicolBolas 你说得对，复制粘贴编码很糟糕。但这不是故意使用非常规函数名称的正当理由。此外，有时复制粘贴可能很有用：OP 可能想要使用 GL 函数调用复制和运行代码只是为了学习它。或者他可能只需要从 GL 文档中复制很长的函数名称。当然，添加:: 不会花费太多时间，但对我来说，这个选项似乎仍然是不必要的过度复杂化。

标签： c++ opengl

【解决方案1】：

您很可能不想这样做，因为它们将不再遵循普遍使用的 C 语言绑定命名约定。通过将GL_ 添加到常量的开头并将gl 添加到函数的开头，整个命名空间问题已经以与语言无关的方式解决了。

你可以在这里做任何你想做的事，但是像 C 或 C++ 这样的语言的全局命名空间已经被你链接到的底层库污染了。例如，在 Windows 上，您拥有 GL 1.1 中的所有功能，只需使用标准 C 语言名称绑定即可。这是一组大约 400 个函数，您可以通过包含平台的 OpenGL 标头获得。

【讨论】：

考虑到对非 C 语言的各种绑定，我会毫不犹豫地将这种约定称为“普遍使用”。 LWJGL 为每个 OpenGL 版本和扩展提供了自己独立的伪命名空间。 OpenTK 将 OpenGL 置于 GL 类中，但删除了成为多余的 gl 和 GL_ 前缀。它甚至根据 C# 约定重命名 OpenGL 枚举器。鉴于有很多方法可以将 OpenGL 绑定到一种语言，为什么 C++必须效仿 C？
@NicolBolas：不要误会我的意思，我很清楚很多很多语言绑定都取消了这个约定。我的观点实际上是，通过包含来自 C 或 C++ 的 gl/gl.h，您将使用原始 gl* 约定拖入一堆函数。如果将所有内容隔离到自己的命名空间中的目的是为了简单，那么在这种情况下会实现相反的效果。您需要编写自己的标头并确保您的软件的任何部分都不包含平台标头以避免这种情况。
"您需要编写自己的标头并确保软件的任何部分都不包含平台标头以避免这种情况。" 是的。 当我将该功能写入 glLoadGen 时，我考虑了这一点。这是关于 OpenGL 加载器的一个非常常见的事情。几乎所有这些都会阻止您手动包含gl/gl.h，如果您尝试在包含他们的标题之前包含该标题之前，它们将无法工作。甚至 GLEW 的标题也是如此。这个问题已经解决了。甚至是wgl.h 问题。
真的不是，一点也不。以 OS X 为例。它具有 gl.h 和 gl3.h，它们旨在相互排斥。可以检测到包含两个标头的情况，仅包含gl.h 而软件其余部分使用gl3.h 提供的接口的情况......不是。您可以轻松地使用原始 C 语言绑定的一个代码模块结束，而使用自定义 C++ 绑定的另一个代码模块，就像在 OS X 上出现的情况一样。
"您可以轻松地使用原始 C 语言绑定来完成一个代码模块，而无需知道它使用您自定义的 C++ 绑定来完成另一个代码模块" 当然，这可能会发生。所以呢？应用程序的一部分可以使用 GLEW，而另一部分使用 glBinding，而第三部分则单独使用 gl.h。最后，它都使用相同的函数与 C 对话。那么问题到底出在哪里？