I have project on Qt4.8 and trying to build it with Qt5.1. I receive lots of
#error gl.h included before glew.h
and
#error glext.h included before glew.h
errors. Seems like it was big changes in Qt5 with OpenGL.. All includes are
#include "GL/glew.h"
#include "GL/gl.h"
#include "GL/glu.h"
glew.h is always the first.
Suposing you only use OPENGL calls in a class where you use functions you need to load using GLEW, then this will work.
What i did to fix this is to include all GLEW h's in the .CPP file, but BEFORE the inclusion of the header file (where the QTGUI which in turn contains OPENGL).
So this is the way for me in GLWIDGET.CPP:
#include <GL/glew.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <GLWidget.h>
As you can see, my GLWidget is a derived class coming from QGLWidget, which needs to include QTGUI and all of that.
It doesn't matter whether the header is included first in some .h file. Header files are not standalone. What matters is the order that includes are seen from the source file.
You seem to have too many header inclusions (generally speaking, you should keep header-to-header inclusions to an absolute minimum). There's nothing that can be done on our end to fix that; you just need to untangle your header issues.
Related
What's the current "best practice" regarding the inclusion of Qt header files when using a modern and recent C++ compiler (e.g. MSVC2015) with precompiled headers activated?
Example:
#include <QStringList>
#include <QTreeWidget>
#include <QListWidget>
vs.
#include <QtCore>
#include <QtGui>
What convention should I choose for a new project?
What are the benefits/drawbacks of either?
What is more common for new projects?
As far as I know, there is no specific limitation/recommendation/advantages/drawback with Qt includes and precompiled headers. When including third party header files (Qt or boost or whatever), the same rules apply.
In general (true for Qt includes, but also for any other third party includes, like STL for instance, and even when including your own code), you should make your includes minimal. The fewer files you include, the faster compilation will be. Including files you don't actually need will make compilation slower. Additionally, if such a header file you included but do not use, is edited/modified (which should not be the case for third parties header files, in general), any file including it will require to be recompiled, even if it does not really use the code included....
So the general rule is to only include files that you really need. So if your file only needs QStringList, prefer including <QtCore/QStringList> rather than <QtCore>.
If you are concerned about compilation time, also make sure you only include files from header files (.h) if necessary, if forward declaration can be used, use it and only include the necessary header file from your implementation (.cpp). This will drastically reduce compilation time of your project when a header file gets modified (read this).
Now, if your project has many files that includes some Qt files, you may use precompiled header to optimize compilation. Those files will then be compiled once and only once. However, as all your files will end up using the same precompiled header (itself including many many header files), you should only do this if:
The precompiled header files should mainly be third party header files, so that they are not meant to change. Because if on changes, then all your files will require to be recompiled...
The compiler must support precompiled header (else, compilation may work but may also end up being slower because every file will end up including all the precompiled header of the project...so probably more files than it actually needs).
I use next in all projects (for precompiled header):
#pragma once
#ifdef QT_CORE_LIB
# include <QtCore>
#endif
#ifdef QT_CONCURRENT_LIB
# include <QtConcurrent>
#endif
#ifdef QT_GUI_LIB
# include <QtGui>
#endif
#ifdef QT_WIDGETS_LIB
# include <QtWidgets>
#endif
#ifdef QT_MULTIMEDIA_LIB
# include <QtMultimedia>
#endif
#ifdef QT_NETWORK_LIB
# include <QtNetwork>
#endif
#ifdef QT_XML_LIB
# include <QtXml>
#endif
#ifdef QT_QML_LIB
# include <QtQml>
#endif
#ifdef QT_QUICK_LIB
# include <QtQuick>
#endif
#ifdef QT_SQL_LIB
# include <QtSql>
#endif
#ifdef QT_PRINTSUPPORT_LIB
# include <QtPrintSupport>
#endif
It will include necessary definitions only if you connect a module. Works well with msvs+qt addin or with cmake based projects (I use cotire).
Including less headers reduces compilation time, and only that, so if you do
#include <QtCore/QStringList>
compilation it's slightly faster than if you did
#include <QtCore>
If you are sure that you depend on everything in QtCore, include it, if not, include each header separately.
I was always thinking that I must include #include "Stdafx.h" line at very top of each header file in project like it is said in description. I have created simple MFC dialog based application with help of wizzard and found that header files not contains #include "Stdafx.h" lines, but cpp ones has them. So, when I must use #include "Stdafx.h" line in cpp and when in h one?
Short answer: in a .h: never; in a .cpp if, and only if, it is configured with precompiled headers (they are by default).
The rationale is that #include "stdafx.h" is used to include the precompiled headers (built when compiling stdafx.cpp). In order for them to be effective they must be the very first line of the compilation unit (not counting blanks or comments). And that very first line cannot be in a header file because the #include that includes it comes first!
I would recommend using #include "stdafx.h" in cpp files only, since you might want to compile one cpp 'with' precompiled headers, and another cpp 'without' precompiled headers.
Also, when you create projects using DevStudio's wizard, these stdafx.h includes will be located in the cpp files.
I have a class called D3DGraphics in a header file called D3DGraphics.h. I have included d3d9.h and my Graphics file works absolutely file.
However, recently I found a header file which was including D3DGraphics.h when it was not using it, so I removed the
#include "D3DGraphics.h"
When I did that, the D3DGraphics header / cpp file suddenly forgot all the DirectX definitions and I got loads of errors like IDirect3D9 and D3DCOLOR_XRGB is undefined!? I have used
#pragma once
in all my header files and I'm pretty sure there is no mutual inclusion so I'm stumped. Why would removing the #include of a file cause that file to stop working!?
Thanks in advance
To anyone who had this problem: I was an idiot. Somewhere in my program I had used
#include <d3d.h>
This caused the directx version to be defined as lower than 9, so in my graphics header when I used #include <d3d9.h>
it did not define any directx9 types (facepalm.)
Try using header guards instead of #pragma once.
i.e.
#ifndef D3DGRAPHICS_H
#define D3DGRAPHICS_H
class D3DGraphics...
#endif
I've been trying to figure this out by myself for months, and that's not an exaggeration.
I feel dirty using the methods I am not since things tend to break and get out of scope when they get complex and I cannot find an answer to this anywhere.
I have a project structure as follows:
Project-Directory/
main.cpp
makefile
SDLMain.h // SDL libraries required to be in the project directory.
SDLMain.m // SDL libraries required to be in the project directory.
--- gamestate/
------ clean.cpp
------ gamestate.cpp
------ gamestate.h
------ init.cpp
--- graphics/
------ graphics.h
------ // more .cpp files
--- logic/
------- logic.h
------- // more .cpp files
--- character
------- character.h
------- // more .cpp files
In main.cpp I have:
// C++ Libraries
#include <iostream>
// Graphical Libraries
//#include <SDL/SDL.h>
//#include <SDL/SDL_opengl.h>
// Custom Libraries
#include "character/character.h"
#include "logic/logic.h"
#include "graphics/graphics.h"
#include "gamestate/gamestate.h"
All the .cpp files in character and graphics etc... include their respective header file which shares the same name as the folder. I.e. clean.cpp, gamestate.cpp and init.cpp and all include gamestate.h.
In each folder there is only one header file, recently reorganised from 1 header file per .cpp.
Basically on this new, more structured system I get scope errors when I attempt to compile my project.
Why is that so if my headerfiles are being included after #include <iostream> and the SDL libraries in main.cpp.
I solved the error by inserting this into all header files:
// C++ Libraries
#include <iostream>
// Graphical Libraries
#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
But then I am including the same thing over and over again and surely this is bad practice.
Not only this, but gamestate.h contains a prototype used by gamestate.cpp to a function in logic.cpp which gets a scope error unless I implicitly include logic.h in gamestate.h even though logic.h is included in main.cpp before gamestate.h.
I thought #include is meant to drag the contents of header files into scope and the functions it prototypes so the compiler knows what to expect.
Why am I getting all these errors about scoping and functions not existing?
Should I make a global.h and #include all the SDL and <iostream> stuff there?
Why can't I access the function prototyped in logic.h from another file included afterwards in main.cpp?
This is sort of a "you can do it many ways, and none are completely right or wrong" question.
But technically, a source file needs to include all headers that it depends on. So if "gamestate.cpp" needs something in "logic.cpp", then "gamestate.cpp" needs to include "logic.h". If EVERYWHERE that uses "gamestate.h" also needs "logic.h", then "gamestate.h" probably should include "logic.h", but I have worked on systems where the rules are: If you are going to use "gamestate.h", you must include "logic.h" first. Note that "gamestate.cpp" is not compiled inside "main.cpp" (unless you commit the heinous crime of including "gamestate.cpp" inside "main.cpp" - but please don't do that).
I like it when you can just use a header file directly, without having to remember the list of header files you must add before it.
Using a "global.h" is probably a bad idea.
So I'm trying to move my OpenGL code from Main() into a specific class that will handle the 3D graphics only when necessary. Previously, the top of my main.cpp file looked like this:
#define GLEW_STATIC
#include <GL/glew.h>
#include <SFML/Graphics.hpp>
#include <cstdlib>
#include <iostream>
#include <fstream>
#include "Game.h"
This worked well enough. What I tried to do was move all the OpenGL-relevant code into methods of the Game class. So I removed #define GLEW_STATIC and #include <GL/glew.h> from the above, and put them into Game.h, such that the top of Game.h now looks like this:
#define GLEW_STATIC
#include <GL/glew.h>
#include <SFML/Graphics.hpp>
#include <cstdlib>
#include <iostream>
#include <fstream>
#include "Environment.h"
When I try to compile, I get the title error, #error gl.h included before glew.h.
Why is this happening, and how can I use OpenGL code (almost) entirely inside the functions of a specific class without this happening?
EDIT:
I have also tried this configuration in main.cpp, in an attempt to make sure that nothing includes SFML before GLEW.
#include <cstdlib>
#include <iostream>
#include <fstream>
#include "Game.h"
#include <SFML/Graphics.hpp>
Unfortunately, that doesn't help (there's nothing else being included that I'm not mentioning here).
Some other library is including gl.h. My guess would be SFML. Make sure you include GLEW first in Game.h and check the places where you include Game.h to make sure you're not including SFML or something else that includes gl.h before Game.h.
If you have something like:
#include <something_that_includes_gl.h>
#include "Game.h"
It will effectively include gl.h before GLEW.
I think I had this issue once, too. It's somehow caused by the way SFML (1.6?) includes the OpenGL stuff.
IIRC (been some time and I don't need GLEW anymore since switching to SFML2) it's due to SFML's Graphics.hpp including GLEW.h, too. Shouldn't happen due to include guards, but I think with some versions this might still happen. It might be possible for you to skip GLEW's header completely, as it's included through SFML anyway.
Which version of SFML are you running? 1.6, 2.0 or the 2.0 with the new API? Also, what's the reason for using GLEW? Something you're missing from SFML? Maybe it's something included in the latest version, so keeps you from having to include it too.