OpenGL without windows.h
Author
How by the rat's ass can I avoid getting windows.h included in every .cpp that uses OpenGL, when building for a Windows system?
A couple of the extension loaders do it as well, although I can't remember which ones exactly. I almost always use GLEE though, so that one probably skips Windows.h as well. I think SDL_OpenGL.h might, and I am pretty sure the GLUT header contains all the required definitions. It's not much.
Author
SDL_opengl.h: line 32, #include <windows.h>
GLee.h: line 57, #include <windows.h>
GLUT doesn't load most extensions.
For some reason both SDL and GLee use DWORD and VOID etc. crap in the GL function prototypes instead of standard types.
GLee.h: line 57, #include <windows.h>
GLUT doesn't load most extensions.
For some reason both SDL and GLee use DWORD and VOID etc. crap in the GL function prototypes instead of standard types.
Well, yes. If your library communicates directly with the operating system, as OpenGL does, you're pretty much stuck with using the OS. Why do you want to avoid windows.h being included?
Author
I'm stuck with using the OS, but since I don't call Windows API functions directly but through the driver, the driver should wrap them and hide such internals.
Including windows.h slows down noticeably compilation speed with Intel's compiler in release builds, even with WIN32_LEAN_AND_MEAN and VC_EXTRALEAN defined. So now I'd have to turn on precompiled headers, and there are various disadvantages to them.
Including windows.h slows down noticeably compilation speed with Intel's compiler in release builds, even with WIN32_LEAN_AND_MEAN and VC_EXTRALEAN defined. So now I'd have to turn on precompiled headers, and there are various disadvantages to them.
Looking for something like that?
Quote:from: glfw.h
// The following three defines are here solely to make some Windows-based
// <GL/gl.h> files happy. Theoretically we could include <windows.h>, but
// it has themajor drawback of severely polluting our namespace.
Author
Looks like GLee.h uses a bunch of Windows defines itself. Here's everything needed in there in place of #include <windows.h>:
// For gl.h
#define APIENTRY __stdcall
#define WINGDIAPI __declspec(dllimport)
// For glu.h
#define CALLBACK __stdcall
//typedef unsigned short wchar_t;
// For GLee.h
typedef void VOID, *LPVOID, *HANDLE;;
typedef unsigned int UINT;
typedef int BOOL;
typedef float FLOAT;
typedef unsigned __int16 USHORT;
typedef unsigned __int32 DWORD;
typedef signed __int32 INT32;
typedef signed __int64 INT64;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct name##__ *name
DECLARE_HANDLE(HDC);
DECLARE_HANDLE(HGLRC);
// For gl.h
#define APIENTRY __stdcall
#define WINGDIAPI __declspec(dllimport)
// For glu.h
#define CALLBACK __stdcall
//typedef unsigned short wchar_t;
// For GLee.h
typedef void VOID, *LPVOID, *HANDLE;;
typedef unsigned int UINT;
typedef int BOOL;
typedef float FLOAT;
typedef unsigned __int16 USHORT;
typedef unsigned __int32 DWORD;
typedef signed __int32 INT32;
typedef signed __int64 INT64;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct name##__ *name
DECLARE_HANDLE(HDC);
DECLARE_HANDLE(HGLRC);
you dont use them directly but opengl does mostly the win32 type's like BOOL and VOID but im sure it does and also how do you think you get a context to draw on? thats win32 also so there no way. Why is that a problem? you could add a header that call both gl and windows.h then call it
Author
gl.h doesn't use BOOL, VOID, etc. Only the two top lines are needed for gl.h The others are because the GLee author decided to use those instead of basic types.
What functions may get called internally is irrelevant, since you're linking to the .lib anyway. Header-contained #includes, on the other hand, end up making a compile-time (as opposed to link-time) dependencies that are generally exponential because one include file includes other include files and so on, and these all get processed and that adds up even if it's just up to the first line #if defined SOME_H... (see Lakos' "Large-Scale C++ Software Design"). Intel C++ compiler with maxed out optimization options is especially slow.
What functions may get called internally is irrelevant, since you're linking to the .lib anyway. Header-contained #includes, on the other hand, end up making a compile-time (as opposed to link-time) dependencies that are generally exponential because one include file includes other include files and so on, and these all get processed and that adds up even if it's just up to the first line #if defined SOME_H... (see Lakos' "Large-Scale C++ Software Design"). Intel C++ compiler with maxed out optimization options is especially slow.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
