【发布时间】：2012-04-21 04:10:24
【问题描述】：
可能是一个非常简单的问题，但它让我很难过。
我有一个基于 SDL/OpenGL/GLEW 的静态库，可以在 Windows 上编译 (gcc/g++) 和链接。在 OS X 上，相同的代码库无法编译，声称它找不到 GL_NUM_EXTENSIONS 和 ::glGetStringi() 的声明 - 这是因为我在混合中加入了 GLEW（只有 SDL 和 OpenGL，它构建得很好OS X 也是）。
// globals.h
#include <glew.h>
#include <SDL/SDL.h>
// graphics.h
#include "globals.h"
bool HasGLExtension(const char* pName);
// graphics.cpp
#include <string>
#include "graphics.cpp"
bool HasGLExtension(const char* pName)
{
GLint numExtensions;
::glGetIntegerv(GL_NUM_EXTENSIONS, &numExtensions); // error
for (int i = 0; i < numExtensions; ++i)
{
if (strcmp(pName, (char*)::glGetStringi(GL_EXTENSIONS, i)) == 0) // error
{
return true;
}
}
return false;
}
- 作为框架构建的依赖库位于 /Library/Frameworks。
- 使用了 -DGLEW_STATIC -DSDL_NO_GLEXT 编译标志（在 Windows 上根据需要 - 即使我删除它们，问题仍然存在）。
- 甚至自动完成功能也确认 glew.h 的位置存在（当然，这不是我遇到的错误，而是符号）。
- 包含 SDL/SDL_opengl.h 只会导致声明冲突。
- glew.h 中存在有问题的定义
我缺少什么明显的东西？
【问题讨论】：
-
如果你仍然包含
<string>，为什么不使用std::string？ -
为什么不引用编译器给出的错误呢？另外，为什么要将命名空间范围
::glGetStringi用于 GLEW C 函数？ -
@Brett Hale：该项目本身是一个 C++ 库，我习惯于指出属于全局命名空间的东西。
-
@daknok_t：好处 > 这样做的缺点。 openGL 与 c 字符串一起工作，因为我不是以编程方式复制、修改、创建字符串等。我很乐意这样做。即使这不是性能敏感代码（不会检查我的游戏循环中的扩展......），我更喜欢只复制一个指针足够的指针，这也意味着不调用可能会或可能不会做的构造函数晦涩的东西，例如分配内存。
-
@iCE-9 - 那么编译器给出的是错误是什么？