oglbase,
Dave writes:
> Mark writes:
> | 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.
>
> i'd still argue it is a practice fraught with peril (probably why
> windows programmers use it). if library developers
> start doing this, i guarantee they won't manage this part of the
> namespace correctly and end up exporting conflicting versions of
> gl* symbols. while this proposal might be fine for application
> developers, any library developer which uses this should have their
> keyboard confiscated.
I agree that there is some peril. Library authors can make one
of a couple choices:
1) Use private function variables for OpenGL extension commands
that they initialize and only they use.
2) Declare named OpenGL extension command function variables
"extern" and rely on the application or perhaps another
library to declare the function variables.
3) Declare and initialize named OpenGL extension command function
variables itself so the application and other libraries do
not have to. A "make OpenGL programming easy" library might
do this.
Each choice has certain +'s and -'s, but library authors and
library users can pick among them. Clearly option #1 is the
safest so "bullet-proof" libraries are encouraged to choose #1.
- Mark
