[SOLVED]Best practice: where to add include files?
-
Don't know if this is the right place for such a question( sorry if not ) but has been bugging me since early morning. Where is the best place to put include files and why, e.g. :
@//myHeader.h
#include<QPushButton>
class FakeClass{}//myCppFile.cpp - include only the header file
#include "myHeader.h"
int main()
{
....
QPushButton someInstance;
FakeClass fakeInstance;
....
}@or
@//myHeader.h
class FakeClass{}//myCppFile.cpp
#include "myHeader.h"
#include<QPushButton>
int main()
{
....
QPushButton someInstance;
FakeClass fakeInstance;
....
}@Thanks in advance!
-
It is better to include as much as you can in cpp-file and include in headers only what is definetely needed in headers (for example classes which enums you use in header). It will increase compilation speed a bit.
-
The cpp files are compiled once (once for each platform on OS X), whereas the header files usually are included far more often. Each #include in the header is parsed this often (and the same goes for the includes in the included file and so on).
So the general advice is commonly to include only headers that you need for the compilation of the header itself.
-
The compiler needs to read(and parse) the header every time it is included so imagine following situation:
in A.h you have #include <QtGui>
in B.h you have #include "A.h"
in main.cpp you have #include "B.h" #include <QPushButton> and implementation of the program that uses solely QPushButtonWhen you are compiling the program, it is parsing though includes(B.h), which includes A.h, which includes QtGui, causing whole qtgui module to be included. While this does not increase size of the binary, all files must be parsed to be sure that everything has taken in account when resolving QPushButton and usage of it.
By removing QtGui include, only #include <QPushButton> in main.cpp will be used to check QPushButton related stuff.
No-one will include main.cpp (or any other cpp file), hence making this chaining not happen.
Am I correct?
-
As Denis said: Always put your include in your .cpp, .h is an exception.
But it's not only about compilation time... Why:Think about you're building a library which uses QtMultimedia internaly. Well, the application who uses it's headers doesn't need to know about it, right?
So, what're going to happen if you put #include <QAudioOutput> in a header that you want to export? The apps who wants to use it can have compilation problems, even if they don't use qtmultimedia.
Well, the correct solution for this problem should be using a d-pointer... But I just wanted to explain my point =)
-
Yepp, you're right.
Also look at this small class:
@
class QPushButton;class FooBar {
public:
FooBar();
~FooBar();
int doSomething();protected: QPushButton *button;};
@You can safely replace
@class QPushButton;@
with
@include <QPushButton>@
but imagine that this little class is included in a whole bunch of "client" classes or cpp files. The client code does not have access to the protected member button and therefore does not need to know the details of QPushButton. If you #include QPushButton's class definition the compiler must parse the header file in every cpp file where our little class is used, but without any use! The button pointer cannot be accessed!
In this situation, using a forward declaration is much better. The QPushButton header must only be parsed in the files where it is actually used.
BTW: This holds for references to a class too. I.e. no need to include QString if you have a const QString &str argument in a method!