标题几乎说明了一切。我昨天在浏览 Stack 时第一次听说了OpenGL Loader Generator项目，我检查了它以研究它比GLEW有什么优势。在项目网站上，他们声明：
这个加载器生成系统用于为您的特定需求创建 OpenGL 头文件和加载代码。与其将每个扩展和核心枚举器/函数都放在一个巨大的标题中，不如只得到你真正想要和要求的东西。
虽然我知道这种方法肯定比 GLEW 更简洁，但我不明白这种方法如何改进编译时间、应用程序性能或与 OpenGL 驱动程序的交互。此外，使用它的过程似乎需要更多维护，因为每次需要使用附加扩展时都必须重新生成扩展源。在使用 GLEW 时（与不使用相比）我从未注意到任何性能损失，所以我很好奇为什么这个项目的开发人员觉得他们有问题需要解决。我错过了什么吗？
为了全面披露，我编写了 OpenGL Loader Generator。
虽然我知道这种方法肯定比 GLEW 更简洁，但我不明白这种方法如何改进编译时间、应用程序性能或与 OpenGL 驱动程序的交互。
它是一个 OpenGL 函数加载库。除了“Function CPP”风格的内联转发函数之外，它只是调用函数指针。就像 GLEW 一样。
两者之间唯一可能的性能差异在于加载这些函数所需的时间（即：初始化例程）。由于这是一个初始化函数，它的一次性性能是无关紧要的，除非它非常慢。
简而言之，提高“应用程序性能或与 OpenGL 驱动程序的交互”不是该工具的目的。它存在干净的标头，其中包含您打算使用的 OpenGL 部分。此外，它还可以让您轻松使用 GLEW 或 GLee 风格的函数初始化，只要您认为合适。
至于“编译时间”性能，我想编译一个 100KB 的标头比一个 800KB 的标头便宜。但由于 GLEW 和我的工具都没有使用元编程或模板等高级 C++ 技术，因此任何编译时间节省的可能性都非常小。
此外，使用它的过程似乎需要更多维护，因为每次需要使用附加扩展时都必须重新生成扩展源。
这当然是使用该工具的一种方式。使用该工具的另一种方法是提前找出适合您的扩展，然后使用它们。
一般来说，当您编写真正的 OpenGL 应用程序时，您会针对特定的 OpenGL 版本编写该代码。此版本由您要支持的最低硬件决定。如果你想支持从过时的 Intel 945“GPU”到 AMD 和 NVIDIA 最新的高端产品的所有东西，你必须针对 GL 1.4（也许是 2.1，如果你感觉真的很勇敢并且愿意做很多事情的话）针对英特尔驱动程序进行测试）。如果您想支持更新的硬件，您可以针对 OpenGL 3.x 版本之一（3.1）编写代码，具体取决于您希望为英特尔 GPU 提供多少支持。
从那里，您可以决定您打算支持哪些更高版本的可选功能，或者仅支持特定于硬件的功能。您有一个您打算使用的东西的列表，因此您检查这些扩展并根据需要有条件地使用或不使用它。
这就是该工具的用途：当您确定了一组特定的扩展和 OpenGL 版本时。如果您想更加灵活，您可以只生成一个包含更多扩展的标头，即使您不使用它们。或者你可以使用 GLEW；我的工具是一个选项，而不是一个要求。
该工具并不意味着适合所有人。它适用于那些知道自己想要什么的人，他们想要拥有不包含他们永远不会使用的千字节 垃圾 扩展 的标题。
它也适用于自动完成等。有了一个干净的标题，你必须筛选出更少的垃圾，你根本不想跟注。哦，它有助于防止您意外使用您忘记检查的扩展程序中的某些内容。因为它不在您的标头中，所以任何调用此类函数或使用这些枚举的尝试都将导致编译器错误。
另一个好处是易于使用。看看这个网站上有多少关于 GLEW 和“未解决的外部”的问题。出现这种情况的部分原因是 GLEW 可以编译为静态或动态库。因此，您必须在代码中使用 a#define在它们之间切换（在 Windows 上）。那很糟。
使用生成器，您只需将标题和源代码粘贴到您的常规构建中。没有要构建或链接的库。只是几个额外的头文件和源文件。
这就是我编写该工具的原因。
我认为没有明显的性能提升，但是您只需使用 OpenGL 函数声明获得更小的头文件/源文件。
GLEW/GLEE 在库中具有所有版本组合 + 扩展 - 这使得它非常大。例如 GLEW 1.7 的头文件有 834kb。
OpenGL Loader为所需的 OpenGL 版本制作自定义文件。这些要小得多（例如（对于核心 opengl 4.2，大约 120kb 标头 + 130kb 源文件）。这将比GLEW 库编译得更快，当然它的输出代码更小。