SFML/OpenGL.hpp doesn't need Windows.h

[vanisher]

Please do not include Windows.h in <SFML/OpenGL.hpp>.

The intention of the header file is good (different include GL path on MacOS), but i won't let Windows.h sneak into all my sources, as they are 100% Windows-clean. Windows.h is huge, and the GL includes don't need any of it.

[Laurent]

They do, GL.h on Windows uses macros defined in windows.h such as APIENTRY. You can't use OpenGL on Windows without windows.h included first -- try it if you're not convinced

But maybe I could be more precise and find which minimal set of Windows headers are needed rather than including the big windows.h. This requires further investigation.

[vanisher]

They do, GL.h on Windows uses macros defined in windows.h such as APIENTRY. You can't use OpenGL on Windows without windows.h included first -- try it if you're not convinced

Heres what my gl.h looks like:

#if !defined(APIENTRY)
#  if defined(__WIN32__)
#    define APIENTRY __stdcall
#  else
#    define APIENTRY
#  endif
#endif

My sourcecode:

#include <GL/gl.h>

int main(void)
{
  //DWORD nothing;  // error: DWORD not defined

  glIndexi(1);
  return(0);
}

> g++ -o test.exe main.cpp -lOpenGL32

...compiles fine only if the DWORD line stays commented.

Maybe we got a different gl.h header?

[Laurent]

Maybe we got a different gl.h header?

Yes, mine doesn't define APIENTRY nor WINGDIAPI, and triggers compile errors if included alone.

I don't know if it would be 100% safe to include Windows headers only with VC++. This would require further investigation too

[vanisher]

Maybe we got a different gl.h header?

Yes, mine doesn't define APIENTRY nor WINGDIAPI, and triggers compile errors if included alone.

Poor MSC users then...

Bottom line is, this issue applies to MinGW users.

Btw., MinGW could be identified by checking:

#ifndef __MINGW32__
  #include <Windows.h>
#endif // __MINGW32__

Cheers.