oglbase-discuss,
Michael Gold writes:
> I'm not so sure the namespace definition needs to be so rigid. In a model
> where extensions are available only through GetProcAddress, its not clear
to
> me that the API has a lock on these symbols in the way you suggest.
I completely agree.
Jon's notion that you CANNOT assign the address of the GL function
to a function pointer variable with the name of the GL function
is senseless.
If the driver has to get an entry point by function pointer
address using {glX|wgl}GetProcAddress, what is the point in saying
that the name be reserved? The name of the command is the OBVIOUS
name for the function pointer variable.
I would assert that if the function pointer typedef for an OpenGL
command is defined in glext.h, the name is "unreserved" so that
applications can use it. And do not declare a function prototype
for the name in glext.h (unless some backward compatibility
define was set that would then not declare the function pointer
typedefs).
Jon, I appreciate your respect for the OpenGL namespace, but
what you are proposing is totally counter to the practice for
Windows programmers today, and it's way confusing to explain.
- Mark
