MissingOpenGLDefinitions within JUCE namespace (not portable without using namespace juce)

When using using namespace juce; opengl-definitions like GL_TEXTURE0 are either a macro (on mac, defined by gl3.h) or an enum (windows, MissingOpenGLDefinitions).

However, without using namespace juce; I would have to add juce:: in front of GL_TEXTURE0 when on windows, which wouldn’t work on mac anymore.
So the code won’t be portable.

However, I actually like the removal of using namespace juce;
Am I missing something, or should JUCE revise the MissingOpenGLDefinitions-trick?

1 Like

I already reported this back in 2019

No response from the JUCE team members tagged back then

2 Likes

These requests will just pile up ad infinitum. IMO, it’s just easier to request the whole lot of macros in a consistent way - so, please see my FR: FR: Wrangle a comprehensive set of OpenGL functions & macros

To add to the FR - the “wrangling” of functions and macros from OpenGL is a totally normal thing to do in order to get access to all functionality necessary at once.

Bump. Ran into this again in another project today. Would be very pleased if the JUCE team would search a solution for this :slight_smile:

1 Like

And again – seems that this one comes up on a regular basis. Why is there no official reaction from the team regarding this since the first report of this issue two years ago? This is really annoying when trying to write clean and portable code without a global using namespace juce

The value in getting OpenGL sorted out properly on all platforms is probably low in that it has the air of working… That and/or FUD.

Anybody familiar enough and wanting to play with OpenGL/any 3D rendering engine knows to jump on this asap.

I’ve made some changes to the way that we load OpenGL symbols which should solve some of the issues raised in this thread.

Given that the change is quite large, it’s currently on a feature branch: generated-opengl-headers. I’d really appreciate any feedback on this potential change, before we merge it to develop. As always, I’m happy to answer any questions you may have about this change.

Some more details can be found in this post: FR: Wrangle a comprehensive set of OpenGL functions & macros - #5 by reuk