Including <QtGui/...> or <...>
-
No, it does not. Both <Module/Class> and <Class> should include the same file since the include path will contain both "toplevel/Qt" as well as "toplevel/Qt/Module" (at least when using qmake projects).
In creator we used to do <QtGui/QLabel> to make explicit which modules we were using. With Qt5 being started and with it moving around classes we switched to <QLabel> style includes to allow building Creator with both Qt4 and Qt5.
-
When using qmake (and this is the best method), I suggest to use <module>. For example, in your main.cpp add this line :
#include<QtGui>
and in the qMakefile add those 2 lines :
CONFIG += qt
QT += guithe qmake will generate the appropriate Makefile and you will not find any problem :)
-
[quote author="issam" date="1342372394"]#include<QtGui>
[/quote]
This has some disadvantages as it includes all headers which has an impact on the compile time.
I prefer to include only what is needed and if possible only in cpp files and in headers use forward declarations. -
[quote author="issam" date="1342372394"]When using qmake (and this is the best method), I suggest to use <module>. For example, in your main.cpp add this line :
#include<QtGui>
[/quote]This is quite suboptimal, the compilation will take longer if you include the whole module. I know it's harder, but when you include just what you need, the compiler has less stuff to parse. I've recently optimised headers in that manner in a project I'm responsible for, and compilation sped up by about 40%.
-
[quote author="issam" date="1342372394"]
@
#include<QtGui>
@
[/quote]Please don't do that. It makes your project slow to compile, and it makes it harder to see what is actually used by your class. Furthermore, this style of "just include everything" can cause hard to fix compilation issues (unneeded interdepencies between files) if you also apply it to your own code. Just include what you actually need, but please do include everything you use (even if it also works without). You don't want your compilation to rely on the fact that some other header you included already includes QString because of some internal need for it. As soon as you change that latter class and you remove the include there, the other file that relied on it will stop compiling. That is just plain annoying.
-
No, it may be usable for quick demo's an wips, but not for anything you plan to distrubute and maintain for any amount of time. What starts as (a component in) a small project may end up as (a component in) a big project. So, for the general case, I think it is bad advice to give. It doesn't really help you either. How much work is it to just #include the actual classes you're using anyway?
-
Well, if you don't stick to including specific headers from the start, and your project is ongoing, it will come to a point (sooner or later) where you will be facing long compilation times and a big effort to fix it. In the optimisation job I've mentioned, I had to look through well over a hundred source and header files and fix them all. It took about 3 days to complete.
So, while you are right that it's not necessary, especially for small projects where compilation time is negligible anyway, it sure is easier to do it right from the very start than to be forced to fix it later.
-
All right, I surrender :)
and I will confess : In my project I began by this :@# include <QtGui>@
And I ended by :
@
#include <QDebug>
#include <QApplication>
#include <QDesktopWidget>
#include <QPushButton>
#include <QLineEdit>
#include <QHBoxLayout>
#include <QVBoxLayout>
#include <QGridLayout>
#include <QTabWidget>
#include <QWizard>
#include <QWizardPage>
#include <QTableView>
#include <QListView>
#include <QStringListModel>
#include <QStandardItemModel>
#include <QFrame>
#include <QGroupBox>
#include <QMessageBox>
#include <QInputDialog>
#include <QLabel>
@It's hard to me but very easy to the compiler ... very easy !
