0

I'm working in a multiplatform project using OpenGL and get to the point where I needed to query the current context. In windows I used wglGetCurrentContext() including windows.h that worked fine.

On the other hand, when tried to compile in linux I'm using glXGetCurrentContext() and including glx.h which internally includes Xlib.h and X.h

It happens that in my source code I have a class called Status but there is a macro called the same in Xlib, i.e. #define Status int, Aha ! big problem now since I use my class everywhere.

What would be the best way to overcome this problem? The ideas I have in mind right now are

  1. Rename my class to something else ... but why?
  2. Use #pragma push_macro("Status") followed by a #undef Status
  3. Find a more robust and portable way to query OpenGL's context

If you have any other recommendation let me know, I appreaciate it very much.

BDL
  • 21,052
  • 22
  • 49
  • 55
BRabbit27
  • 6,333
  • 17
  • 90
  • 161
  • 2
    Limit the number of files that include glx.h and then undefine the macro. Don't include in a header! –  Nov 03 '17 at 09:46
  • 3
    Could you move the dependency in a unique file ? where you can `#undef Status` safely ? – Jarod42 Nov 03 '17 at 09:47

2 Answers2

3

at a bare minimum, you may isolate glXGetCurrentContext() into its own translation unit:

myGlXGetCurrentContext.hpp

GLUint myGlXGetCurrentContext();

myGlXGetCurrentContext.cpp

#include<glx.h>
GLUint myGlXGetCurrentContext(){ return glXGetCurrentContext(); }

whatever.hpp

#include<myGlXGetCurrentContext.hpp>
...
Rabbid76
  • 202,892
  • 27
  • 131
  • 174
Massimiliano Janes
  • 5,524
  • 1
  • 10
  • 22
-3

Try to put Your classes in namespace.

http://en.cppreference.com/w/cpp/language/namespace

https://msdn.microsoft.com/en-us/library/5cb46ksf.aspx

armo
  • 54
  • 3
  • I wasn't talking about MACRO but about classes. – armo Nov 03 '17 at 09:51
  • 1
    My first thought was namespaces but after thinking about the problem it doesn't matter cause the pre-processor will replace the name no matter what namespace or whatever, so no, namespace doesn't help. Thanks for the time to answer though – BRabbit27 Nov 03 '17 at 09:51
  • *"but there is a macro called the same in Xlib"*. It would be a valid solution if Xlib doesn't use evil macro. – Jarod42 Nov 03 '17 at 09:52
  • 1
    The best way is to use some kind of prefix for own classes from the begining. But now this cause You have to rename all of our classes. – armo Nov 03 '17 at 09:53
  • @armo that's a good point but sometimes we get into dev teams were code's been developed for long time before we are there. Also is the first time it happens to me so either I haven't code hard enough or was super lucky not getting this error in the past, now I think I will take your advise for future projects ;) – BRabbit27 Nov 03 '17 at 09:57