In your message of 4 April 2000 you write:
> On Tue, 4 Apr 2000, Michael Gold wrote:
>
> > I don't agree with your interpretation. I assert that (b) addresses your
> > concerns, and most of mine as well.
>
> As I said before, if accepting (b) will avoid (c), I'll accept (b).
>
> I'm suprised that (c) enthusiasts would find having to define a new
> symbol (option (b)) somehow more palatable than including a new header
> file (option (a)) - but it's not a big deal.
>
> I believe that in the fullness of time, the oglbase spec would come to
> be the standard on all non-windoze machines. Hence, in a year or two
> from now you'll just be able to assume the existance of oglbase and
> unconditionally include glext.h on non-windoze machines.
>
> You'll have (for portable code):
>
> #include <GL/gl.h>
> #include <GL/glu.h>
> #ifdef WIN32
> #include <windows.h>
> #else
> #include <GL/glext.h>
> #endif
Not quite. And this is the whole point. If you want to be really
compliant, you have to use glXGetProcAddressARB to retrieve function
pointers. The way of how you figure out of whether to include glxext.h
or not is IHMO really a no-brainer. It's really the semantics of how
you use the extensions that changes:
#ifdef GL_EXT_point_parameters
#ifdef WIN32
pfn = wglGetProcAddress("glPointParameterfEXT");
#else
#ifdef GLX_ARB_get_proc_address
pfn = glXGetProcAddressARB("glPointParameterfEXT");
#else
pfn = glPointParameterfEXT;
#endif
#endif
#endif
If glext.h is included, then the check for GLX_ARB_get_proc_address
must be present, or things break. So in reality you have to change
source code substantially to make it work according to the spec.
So what it boils down to is whether to break existing code by default
(option c), or not (a or b). And on a second level, whether gl.h can
be made consistent with glext.h or not (b and c, vs a).
It should be also clear that using option c is no guarantee for
forcing an application programmer to update the source-code to be
compliant with the standard, as the following code (as it is today)
might still compile and work (if the libGL.so exports the right
symbols):
#ifdef WIN32
(*wglGetProcAddress("glPointParameterfEXT"))(...);
#else
glPointParameterfEXT(...);
#endif
So any of those options seems to be more a matter of personal taste
(b vs. c) as opposed to which one would be a technical better way to
deal with things, looking forward.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
