> From: Stephen J Baker [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 09, 2000 10:11 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [oglbase-discuss] CALL FOR VOTE: gl.h/glext.h
>
> It's not exactly difficult to find those naked references - a
> well-phrased 'grep' will get them all...and it's not like this
> is something you'll do by accident. This seems a very tiny
> benefit. Once people are writing ABI-compliant programs routinely,
> I doubt they'll even *think* of calling a naked extension function
> anymore.
Here's why I think grep is unrealiable and a compile-time solution is the
only robust means for detecting such naked references:
I expect some people will want to name the function pointers after the
functions themselves, e.g.
PFNGLACTIVETEXTUREARB glActiveTextureARB =
glXGetProcAddress("glActiveTextureARB");
glActiveTextureARB(GL_TEXTURE0_ARB);
This is a prefectly valid technique (although I know Jon disapproves of
overloading the symbol name for a locally declared pointer). The benefit of
this method is that all the system-dependencies on static links vs
GetProcAddress can be isolated to the initialization code, and all
subsequent references to these functions can be written as if they were
statically linked. This seems highly desireable to me both cosmetically and
for portability between platforms, and has the added benefit of trivializing
the changes you would make to a legacy application in order to make it
OGLBASE-compliant.
In fact this is the exact case which makes option A so undesireable; if gl.h
includes a declaration for glActiveTextureARB, the function pointer name
would have to change to avoid a compile-time error.
As an aside, the purist in me would prefer we rethink the decision to allow
static linking of the GL_ARB_multitexture entry points. It seems a bit
inconsistent to statically link one extension but no others, and I'm
thinking of what will happen if we decide to promote another extension to
static linkability in the future. The very problem I describe above will
come back for that extension, since it is in both gl.h as a prototype and
glext.h as a typedef. I think the safest solution is to never promote any
more extensions to static linking, and reserve that for core functionality,
even if its too late for GL_ARB_multitexture. (Its not too late is it?)
Of course all of these problems go away if people take Jon's advice and
don't overload the symbol name. But as I have argued, I think it is a
desireable technique which should not be precluded by our definition of the
SDK.
-- Michael
