What is PFNGLACTIVETEXTUREARBPROC?

Many tabout texture will incluse this pointer PFNGLACTIVETEXTUREARBPROC lActiveTextureARB = NULL;,
It seems a callback function, What is its meaning?

Its prototype function is
void ( APIENTRY * glActiveTextureARB)( GLenum texture );
thus PFNGLACTIVETEXTUREARBPROC should be APIENTRY.

this stucture seems to use for windows.

See:

The ARB suffix is from ancient times (1990s) when the extension ARB_multitexture was needed to get access to this function pointer, and you had to fetch the function pointers with {glX,wgl}GetProcAddress.

Now this is just a legacy compatibility shim you’ve long been able to ignore. Just use the core symbol glActiveTexture() and forget about it.

[QUOTE=Dark Photon;1264775]See:

The ARB suffix is from ancient times (1990s) when the extension ARB_multitexture was needed to get access to this function pointer, and you had to fetch the function pointers with {glX,wgl}GetProcAddress.
ze
Now this is just a legacy compatibility shim you’ve long been able to ignore. Just use the core symbol glActiveTexture() and forget about it.[/QUOTE]

arb is an orginazition, which made the regulars. the doc told that.
you mean this command with arb suffix will be abandoned for good?
thank

This is content from the page, but no any information on FNGLACTIVETEXTUREARBPROC glActiveTextureARB
Parameterstexture
Specifies which texture unit to make active. The number
of texture units is implementation dependent, but must
be at least 80. texture must be
one of
GL_TEXTUREi,
where i ranges from zero to the value
of
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS
minus one. The initial value is
GL_TEXTURE0.
Description
glActiveTexture selects which texture unit subsequent texture state calls will
affect. The number of texture units an implementation supports is
implementation dependent, but must be at least 80.

Here is the glActiveTextureARB , but no information on FNGLACTIVETEXTUREARBPROC
http://www.xfree86.org/current/glActiveTextureARB.3.html#toc

eqn not supported
Parameters

texture
Specifies which texture unit to make active. The number of texture units is implementation dependent, but must be at least two. texture must be one of GL_TEXTURE$i$_ARB, where 0 <= i < GL_MAX_TEXTURE_UNITS_ARB, which is an implementation-dependent value. The initial value is GL_TEXTURE0_ARB.

Description
glActiveTextureARB selects which texture unit subsequent texture state calls will affect. The number of texture units an implementation supports is implementation dependent, but must be at least 2.

Vertex arrays are client-side GL resources, which are selected by the glClientActiveTextureARB routine.

At last we find it which was defined by SGI in head file of glext.h

typedef void (APIENTRY * PFNGLPOINTPARAMETERFARBPROC)(GLenum pname,
GLfloat param);
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVARBPROC)(GLenum pname,
const GLfloat *params);

then we can use to define a pointer.
share it for all out there.

The PFN* names are typedefs for function pointers. They’re used for declaring variables (or structure fields) which will hold a function pointer returned from wglGetProcAddress(), glXGetProcAddress, or similar.

On Windows, opengl32.dll only exports the symbols from the OpenGL 1.1 API. Any other function (i.e. those from later versions or from extensions) can only be accessed by using wglGetProcAddress() to obtain a function pointer.

On Linux, libGL.so typically exports symbols for all functions which were known at the time that it was generated. So the set of exported symbols will depend upon the version of the library, with later versions exporting more symbols than earlier versions. If an executable or library imports a symbol which doesn’t exist in the system’s libGL, the program will fail to execute. If you want to write code which uses newer functions where available, but will still run on older systems, it’s necessary to access those functions via glXGetProcAddress() (after checking that both the client library and the X server support the corresponding version or extension) so that the symbol doesn’t become a hard dependency.

Libraries such as GLEW exist to deal with this automatically in a cross-platform manner.

[QUOTE=GClements;1264786]The PFN* names are typedefs for function pointers. They’re used for declaring variables (or structure fields) which will hold a function pointer returned from wglGetProcAddress(), glXGetProcAddress, or similar.

On Windows, opengl32.dll only exports the symbols from the OpenGL 1.1 API. Any other function (i.e. those from later versions or from extensions) can only be accessed by using wglGetProcAddress() to obtain a function pointer.

On Linux, libGL.so typically exports symbols for all functions which were known at the time that it was generated. So the set of exported symbols will depend upon the version of the library, with later versions exporting more symbols than earlier versions. If an executable or library imports a symbol which doesn’t exist in the system’s libGL, the program will fail to execute. If you want to write code which uses newer functions where available, but will still run on older systems, it’s necessary to access those functions via glXGetProcAddress() (after checking that both the client library and the X server support the corresponding version or extension) so that the symbol doesn’t become a hard dependency.

Libraries such as GLEW exist to deal with this automatically in a cross-platform manner.[/QUOTE]
Thank you very much for the excellent answer.
I wonder why they use so long word with capital letter? very hard to recognize. very hard to memory

Using all upper-case for type names is common on Windows (which is probably where this convention originated). Similarly, the “pfn” prefix is conventional for pointer-to-function. The trailing “proc” seems to be unnecessary.

But the naming is at least consistent. Given a function name, prepend “pfn”, append “proc”, and convert the result to upper case. So glActiveTextureARB -> pfnglActiveTextureARBproc -> PFNGLACTIVETEXTUREARBPROC. I suppose that this makes it simple to automatically generate code from a list of function names.

[QUOTE=GClements;1264813]Using all upper-case for type names is common on Windows (which is probably where this convention originated). Similarly, the “pfn” prefix is conventional for pointer-to-function. The trailing “proc” seems to be unnecessary.

But the naming is at least consistent. Given a function name, prepend “pfn”, append “proc”, and convert the result to upper case. So glActiveTextureARB -> pfnglActiveTextureARBproc -> PFNGLACTIVETEXTUREARBPROC. I suppose that this makes it simple to automatically generate code from a list of function names.[/QUOTE]

yes, that is common in windows. but its too long , head will be spinning as soon as seeing it. this written glActiveTextureARB -will be well. but PFNGLACTIVETEXTUREARBPROC. is defined by that system inner.