Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace macro with inline functions #71

Closed
pixeljetstream opened this issue Jan 12, 2016 · 6 comments
Closed

Replace macro with inline functions #71

pixeljetstream opened this issue Jan 12, 2016 · 6 comments

Comments

@pixeljetstream
Copy link

Hi,
with the removal of MX support and added core, it would be nice to convert from the macro usage to inline functions. Currently am doing this in "post" by parsing the glew headers and replacing the macros with some lua scripts, but it would be nice if the stock GLEW offers this functionality. I've also added a GLEW_USER_ASSERT macro that can be defined optionally, to prevent calling a NULL function pointer.

GLEW_FUN_EXPORT PFNGLNAMEDPROGRAMLOCALPARAMETERI4IEXTPROC __glewNamedProgramLocalParameterI4iEXT;
__inline void glNamedProgramLocalParameterI4iEXT(GLuint program,GLenum target,GLuint index,GLint x,GLint y,GLint z,GLint w){
GLEW_USER_ASSERT(__glewNamedProgramLocalParameterI4iEXT);
__glewNamedProgramLocalParameterI4iEXT(program,target,index,x,y,z,w);}

one benefit of inline is that it works well with showing the function arguments in IDEs

@nigels-com
Copy link
Owner

This would break compatibility unfortunately. There is code that directly queries and sets function pointers.

@nigels-com
Copy link
Owner

Aside from burning bridges in terms of adding back MX mode, it does seem like GLEW_GET_FUN could be conditionalized to opt-in to inlined functions. But that might not suffice for IDEs.

@pixeljetstream
Copy link
Author

well the function pointer "set" in glew.c could be replaced by not using the macro and instead the mangled name directly?

it only breaks code compatibility if users assigned function pointers themselves using the macros outside of the library.

@nigels-com
Copy link
Owner

Current thought is to only #define GLEW_GET_FUN if it's not already defined. This will allow for wrapper functions declared elsewhere to be used instead of directly mapping glFunc to __glewFunc, as is the usual arrangement.

@nigels-com
Copy link
Owner

There is a change to the master branch to avoid defining GLEW_GET_FUN etc, unless necessary. This leaves the binary API untouched, but opens the door to having an alternative layer of macros or functions for calling into OpenGL. I don't have any immediate plans in regard to naming or generating alternatives to glew.h, but it's a first step.

@nigels-com
Copy link
Owner

Closing, unless there is anything further for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants