Get rid of includes
-
If there is one thing I really get annoyed over in C/C++ it's the includes. Why on earth would we have to handle all that crap manually?
My solution to this problem when doing embedded programming with AVR-GCC was to put all includes I ever needed in a file "includes.h" and then add "includes.h" to all source files. As it's legal to declare something infinite times it should be okey, I guess?
However, this doesn't work in Qt as it seems. If the includes for a GUI arent "directly" included in mainwidow.cpp a lot of weird stuff happens. For instance it was impossible to connect slots from the buttons in the GUI.
So, is there a way to get rid of the includes? Basically, I just want to include it all, all libraries and all my other header files automatically. If would never give my own function a name from the library anyway, as that is just bound to create confusion. Is this done alot, or why is the tedious include process ever present?
I think it's completely ridicolous having to go 1971 and add a new header manually to all source files.
-
You project will take more time to build if you include all the headers to each source file. Through precompiled headers can speed this up.
For Qt, you can do this too. But you should make sure that all your-own-headers that contains Q_OBJECT have been preprocessed by moc.
-
Hi,
CodaxX your still thinking like someone in 1971. Just that the syntax hasn't changed much, that doesn't mean the programming style did not! For embedded systems it might work to put all header files in one include file and have fun, but then again you let everybody know all about all the other modules. When thinking more object orientated you e.g. introduce module header and only include those. Then only when the module is needed, you include that header, not everything in the entire project! Protect yourself from unwanted calls and links!
And yes, Qt is very well capable in doing a global header include.
If you include them all every where you might even get include loops and added dependencies! If you known and think about who includes who and you change a single header file you only need to test/debug the files the DEPEND on it, not ENTIRE program. The entire program might get mixed up when a single header file is changed!! If you don't trust me, simply forget a } in a header file, add a ; extra or a #ifdef .. without #endif.
Do that in your first included header and a HOLE lot of shit happens!!
Do you really want that kind of dependencies?? -
Some of my colleagues use a similar structure, with a header file combining many include. Also Qt includes.
Can you post your "includes.h"? Maybe there's just a problem in there.
Do you use proper include guards? -
Jeroentje: Well, for bigger project that might be better, actually I don't know.
But I haven't ever been close to having to create different modules in a single program so similar that they could coincide.Therefore, I would just want a checkbox like "Compiler, I trust you to do includes and declarations for me". If I ever wanted something else I could just uncheck it.
1+1=2: Okej, but as you say it should be easy for a compiler to get rid of that speed problem.
Asperamanca: It seems like the problems started when I put
#include "ui_mainwindow.h"
in a separate includes.h. I did compile I think, but the method for graphically adding slots to pushbuttons in the main UI stopped working.
-
Well, I join the other: centralizing the header file inclusion into one unique file is a very bad idea. You'll have to recompile the whole project at each change and it will increase the size of your program.
C++ is quite a low level programming language, so you have to deal with the low level stuff. -
What you could do is put all Qt includes you'll ever need in your project into one header file. Then include that one header prior to any other includes you might have.
If you do something like this for your own header files, you sooner or later run into circular dependencies.
If "x.h" depends on "y.h", but "y.h" also depends on "x.h", this just will not work. And with all your headers in a single header file, it also means that each header file would basically include itself, which drives the compiler nuts. -
Hi,
CodaxX, also with small and easy to maintain projects it is already a good idea to generate modules and expand from there. If you want to minimize includes for Qt there are "extended" includes like
@
#include <QtWidgets>
#include <QtGui>
@
Those take a lot more time to compile because all GUI elements are included in your project, so I would recommend against it.
Also, like Asperamanca wrote, you will get circular dependencies if you try to include them all in a single header file. So please don't, it will come back and bite you in the a**. -
This is the way that C and C++ work. There are plenty of other languages that don't use headers if you don't like it.
Some editors can help you include the right headers, and there are tools like 'include-what-you-use' that can help with getting just the right includes.
Paul
-
So the compiler cant sort out circular dependencies? According to my experience compilers at least can solve headers including themselves.
paulf: Yes but is there another language that is available in a package like Qt?
I'm thinking about trying Visual Studio with C# but that is not cross platform though. -
Circular dependencies are not the only problem. There are many many subtleties when talking about headers, especially considering macros and templates. A simple #ifdef can make a header look completely different in two include spots depending on what symbols are defined in that scope, and that is one of the simplest examples. Templates are usually defined (not just declared) in the headers, and the compiler needs surrounding scope to trigger the right instantiation.
The argument about other languages dealing with it is shallow. C++ is a lot more complex language than say Java or C#, mainly because of macros and templates.
It is advised to put minimal set of includes in headers. Only(but all) those that are needed. Also use forward declarations! These make tremendous difference in compile times in larger projects. Use precompiled headers for library includes and stuff that doesn't change often, like utility classes etc.
Don't create uberheader files. These are evaluated(copy/pasted almost) at each and every include site and will make your project compile times abysmal. Also even a semicolon added in any of the includes will cause the whole project to recompile. This is a bad bad idea if you value your time.
The C++ standardization committee has recognized the problems with headers and is working on a new paper called modules. This won't get into the language until c++17 or later though. The idea is something similar to C# using but, as I said, c++ is a lot more complex language and there are many more subtleties to iron out. "Clang":http://clang.llvm.org/docs/Modules.html has some experimental implementation of it if you're interested, but it's a very early preview and things will certainly change. You can also see this "great talk":http://youtu.be/4Xo9iH5VLQ0 about it on youtube.
-
Well, it's the preprocessor that handles #includes, not the compiler. And the preprocessor is very dumb, it just does text replacement. The preprocessor/compiler cannot figure out circular dependencies alone, i.e., you will get an error like
a.h:1:15: error: #include nested too deeply
or
"b.h", line 1: Error: Too many open files: "a.h". Aborting ....
The usual technique to avoid this is include guards or something like #pragma once. (Here I'm assuming a conventional compiler - I have used one compiler [IBM VisualAge C++ 4 I think it was] that had a 'database' model, and you just had to add the source files and headers to the project and the compiler would sort it all out - great idea, nightmare for porting any existing makefile based project).
As for other languages, the main one that springs to mind is Java.
Paul
