2.2.1 Data Conversion For State-Setting Commands
…
An implementation must use exactly the number of
bits indicated in the table to represent a GL type.
…
但是所谓的OpenGL registry(gl.xml – 官方可解析的OpenGL API规范),天真地将这些类型定义为对应C类型的别名.
... <type>typedef short <name>GLshort</name>;</type> <type>typedef int <name>GLint</name>;</type> <type>typedef int <name>GLclampx</name>;</type> ...
这可能是不安全的.
为什么不使用固定宽度类型？
为什么没有预处理器逻辑来确定正确的类型？为什么没有类型大小的编译时检查？
更重要的是,在制作OpenGL函数/扩展加载器时,我该如何定义这些类型？
It is potentially unsafe.
是的.
所以？
只要它实际上不安全,只要你不尝试在没有提供这些类型的预期大小的奇数球平台/编译器上运行此代码,它就没问题了.它适用于GCC,Clang,VC和几乎所有其他主要编译器.这些定义适用于Windows,MacOS,Linux,Android,iOS以及许多其他系统和ABI.
我理解更强烈地遵守C和C标准的愿望.但实际情况是,这些定义适用于大多数使用中的实际系统.对于不合适的系统,该系统的各个OpenGL提供商可以为这些系统提供替代定义.
Why fixed-width types weren’t used instead?
因为在这种类型之前存在OpenGL.记住：它们的历史可以从C99 / C 11开始; OpenGL可以追溯到1992年.
Why no compile-time checks of type sizes?
早在1992年,C就没有标准化了.当时可能存在什么“编译时检查”？此外,OpenGL是用C语言定义的,C的编译时计算能力主要由极端宏编程技术组成.
And what’s more important, when making an OpenGL functions/extensions loader, how should I define those types?
除非你有特殊的需要,否则就像gl.xml所说的那样定义它们.