I have been making several games with the Allegro API and C++. I have also been putting all my classes in 1 big main.cpp file. I tried many times to make .h and .cpp files, but my big problem is I have trouble with #including at the right place. For example, I want all my classes to access the allegro library without #including allegro.h everywhere. Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included. Is there also a way to globally include something throughout my entire program?
Thanks
I want all my classes to access the allegro library without #including allegro.h everywhere.
Why? That is how you do it in C++ land.
Could someone please explain how to correctly #include things. In .Net, everything seems to come together, but in c++ one thing cannot be used before it is included
Conceptually, in .NET, it is not much different at all. You still have to place "using " at the top. The difference there is that, in .NET, you could also write this every time if you wanted to:
void Foo( System.Drawing.Drawing2D.BitmapData bData ) { }
A common way to do this is to have a master include file that includes all of the others in the correct order. This works especially well if you use precompiled headers so
in precomp.h
#include <stdio.h>
#include <allegro.h>
.. etc.
in myfile.cpp
#include "precomp.h"
in myfile2.cpp
#include "precomp.h"
and so on.
Related
I know in C++ you have to use the "#include" statement to include libraries and headers, like:
#include <iostream>
#include <string>
#include "my_header.h"
But after some time, that can look very ugly, having a load of includes in your files. I wanted to know if there is some way where we can call just 1 file to include EVERYTHING we'll need in the C++ project. Kind of like...
"include_everything.h"
#include <iostream>
#include <string>
#include "header1.h"
#include "header2.h"
and then in our .cpp file, could we go?
#include "include_everything.h"
// write code here...
If it is possible, is it lawful? Does it abide by the C++ coding laws?
Thanks in advance,
Gumptastic
If that is the only rule you decide not to follow you will probably be fine. But, depending on what some of those headers contain (macros, #defines, etc) you could get a horrible mess in the end.
I've seen cases where people included what they thought they needed (often ended up being much more than was needed as they failed to consider forward declarations). On a large software project, each CPP file ended up loading nearly every include file anyway (due to chaining). Often the same file would get loaded multiple time and only excluded once the #ifndef statement at the top was triggered. The OS ended up opening over 100k files for each compile even though only there were only 50k files in the project. In a horrible situation like that it might help.
It can save time for developers as they, generally, won't have to search out where something is defined and add it to their include list for every file they work on. Do it once and forget. Let the compiler tell you if a new file needs to be added to 'everything'.
Aside from the macro problem you might run into issues with overlapping names and such if you don't properly use namespaces. Also, template classes often have real code in the header file. This can create churn.
It might also cause problems if people are using global variables and they are eclipsing local variables. It might be hard to figure out where that global 'i' is defined and being pulled in from if you have to search all files in 'everything' instead of just the files in your include list.
You can do it. If its just you and includes bug you, go for it. If you are your buds are doing something, sure. You are going to serious looks from people if you try to do this on a medium sized project or larger.
At best, I wouldn't suggest using to go beyond grouping tightly bundled headers together into a more coherent API.
You can do this, but it might affect compilation time.
The C(++) #include compiler instruction means nothing more than "Before you compile, copy and paste the content of that file here". That means when you include more headers than necessary, it will take a bit longer to compile each source file. But when that's not a concern for you, go ahead.
Yes, you can do it. You may recursively include headers.
However, If you are including so many headers that this is a problem, either you're including ithings you don't need to include or your source files are way too expansive.
Consequently, it's very rare to do this and I'd go so far as to consider it a big code smell. The only time you really want to do it is when you're going to precompile that include_everything.h.
I am trying to learn how to deal with a lot of includes, and still keep my code tidy.
I am programming a Qt application and I have put files commonly used (and that doesn't change) in a file called "Util.h".
Util.h
#pragma once
#include <Core/IObserver.h>
#include <Core/Math.h>
#include <QAction>
#include <QDockWidget.h>
#include <QFileDialog>
#include <QGraphicsBlurEffect>
#include <QLabel.h>
#include <QMainWindow.h>
#include <QMenu.h>
#include <QMessageBox.h>
#include <QShortcut.h>
#include <QSignalMapper>
#include <QSound>
#include <QString>
#include <QTimer.h>
#include <QTreeView>
#include <QStandardItemModel>
// Path to icons
#define ICON_PATH \
"../../Assets/GUI/Icons/"
This I then include it in almost all of my header files
#include "Util.h"
#include "Manager_Docks.h"
#include "Manager_Tools.h"
#include "Manager_Console.h"
#include "ui_MainWindow.h"
...
Is there a better way of doing it?
Does this slow down compile time much?
I'm also thinking of only including Util.h in every .cpp only, and have a separate Header_Util.h for header files, looking something like this
Header_Util.h
#pragma once
class IObserver;
class QAction;
class QDockWidget;
class QFileDialog;
...
Is this a better solution?
Also, I am aware that there is something called precompiled headers, but have never used myself. Is this perhaps a solution to my problem and something I should look into? I'm on Windows using VS2012 if that makes any difference.
...and to summarize all questions. What would you have done in my place?
TL;DR: Generally, it's best to eliminate unnecessarily visible headers when developing C++ or C.
Is there a better way of doing it?
It's generally a very bad idea when your project is not small. Most sources won't need to see the declaration of most files, and those are high level objects. At least divide it by category.
Does this slow down compile time much?
Generally, yes. Example: Do most of your source files need to know about the UI library? Probably not.
Is this a better solution?
Yes. The forward declarations' cost is very very small.
Also, I am aware that there is something called precompiled headers, but have never used myself. Is this perhaps a solution to my problem and something I should look into?
For some builds, they can save a lot of time. For others, they may only slow things down. If you choose to use them, then measure the build times to confirm which is better for your project and the includes you need.
Typically, you find all your sources don't need to know about something very high level and large (e.g. a GUI library and abstraction layer). Only a portion of the sources generally need to know about those higher level libraries. This is often a good point to break up your codebase into smaller targets/libraries.
...and to summarize all questions. What would you have done in my place?
I wouldn't stuff all those high level libraries/headers in a header for all sources to see. It's painful to undo in large codebases and tends to cost a lot in build times along the way. Headers containing forward declarations are good.
What you're doing is common, although it would be placed within a precompiled header.
A precompiled header (along with a precompiled.cpp) is just a header that will be compile first. The obj file from this compilation can then be directly included into other headers. This prevents all your .cpp files from compiling common header files and cpp files over and over and over again. This speeds up compile times by orders of magnitude.
Setting up a precompiled header is quite simple, and there are quite a few resources online for doing such.
Should I #include everything I need in every header/cpp file? I am working on a 2d game engine atm (for practice mostly) and in reviewing my code I realise that I repeat string and vector in almost every file. Is this an issue and how do I deal with it?
I've always had the opinion that every class or module you write should stand on it's own two legs, so to speak. I really enjoy generic programming (I'm including my own script language in the engine, with my own drafted script engine) but I also realise it could cause a lot of overhead and confusion.
I would stick to including <string> and <vector> only where necessary.
As for making sure individual header files stand on their own, I like how the Google C++ Style Guide deals with include order. Basically, always list the corresponding foo.hpp include before all other includes in foo.cpp. That way, we know that foo.hpp won't expect something to be included before it and fail if it isn't there.
It's not an issue. You should include, in every file, the absolute minimum dependencies- no more, but no less.
Sometimes in C++ the order of the includes matters. That is the case of openGL using :
1.- Right way:
#include <windows.h> // Header File For Windows
#include <gl\glu.h> // Header File For The GLu32 Library
2.- Wrong way:
#include <gl\glu.h> // Header File For The GLu32 Library
#include <windows.h> // Header File For Windows
Does this happen just for some specific headers or is it kind of a
random problem difficult to prevent a priori?
If that is the case:
How can I know the right order of the includes?
Just some specific headers. Some might call it a design flaw.
You can't. Look at the error messages you get and sort them out carefully. On windows, putting windows.h first is probably a good idea.
The order does not matter for C++ Standard Library includes.
For other libraries it should not usually matter (unless they specifically say so).
For specific platforms, it may matter and it is usually specified clearly when it does.
For ex:
On Windows #include <windows.h> comes before all the other includes.
Also,
#include <stdafx.h>
which is a MSVC++ specific header needs to be included before everything else if you're using precompiled headers.
For windows you need the #include <windows.h> first.
Then in the header files avoid #include - prefer forward declarations instead.
Save less compilation when you just change one header file.
At one time, a fair number of well-known C programmers advised that no header should include any other header -- it should be up to the user to include the correct headers in the correct order to make things work. This worked (and continues to work) pretty well for small projects that don't involve too many headers.
For larger projects, however, keeping track of all the header dependencies can/does become substantially more difficult, to the point that it's nearly unmanageable in many modern code bases. Most modern headers themselves include any other headers upon which they depend.
Unfortunately, that means we frequently end up with a rather confusing mixture of the two. There's not much you can do beyond just dealing with it when it arises, by finding what headers you need to include and in what order.
Suppose i have the following code (literally) in a C++ source file:
// #include <iostream> // superfluous, commented-out
using std::cout;
using std::endl;
int main()
{
cout << "Hello World" << endl;
return 0;
}
I can compile this code even though #include <iostream> is commented-out:
g++ -include my_cpp_std_lib_hack source.cpp
Where my_cpp_std_lib_hack is a file in some central location that includes all the files of the C++ Standard Library:
#include <ciso646>
#include <climits>
#include <clocale>
...
#include <valarray>
#include <vector>
Of course, i can use proper compilation options for all compilers i care about (that being MS Visual Studio and maybe a few others), and i also use precompiled headers.
Using such a hack gives me the following advantages:
Fast compilation (because all of the Standard Library is precompiled)
No need to add #includes when all i want is adding some debugging output
No need to remember or look up all the time where the heck std::max is declared
A feeling that the STL is magically built-in to the language
So i wonder: am i doing something very wrong here?
Will this hack break down when writing large projects?
Maybe everyone else already uses this, and no one told me?
So i wonder: am i doing something very wrong here?
Yes. Sure, your headers are precompiled, but the compiler still has to do things like name lookups on the entire included mass of stuff which slows down compilation.
Will this hack break down when writing large projects?
Yes, that's pretty much the problem. Plus, if anyone else looks at that code, they're going to be wondering where std::cout (well, assume that's a user defined type) came from. Without the #includes they're going to have no idea whatsoever.
Not to mention, now you have to link against a ton of standard library features that you may have (probably could have) avoided linking against in the first place.
If you want to use precompilation that's fine, but someone should be able to build each and every implementation file even when precompilation is disabled.
The only thing "wrong" is that you are relying upon a compiler-specific command-line flag to make the files compilable. You'd need to do something different if not using GCC. Most compilers probably do provide an equivalent feature, but it is best to write portable source code rather than to unnecessarily rely on features of your specific build environment.
Other programmers shouldn't have to puzzle over your Makefiles (or Ant files, or Eclipse workspaces, or whatever) to figure out how things are working.
This may also cause problems for users of IDE's. If the IDE doesn't know what files are being included, it may not be able to provide automatic completion, source browsing, refactoring, and other such features.
(FWIW, I do think it is a good idea to have one header file that includes all of the Standard Library headers that you are using in your project. It makes precompilation easier, makes it easier to port to a non-standard environment, and also helps deal with those issues that sometimes arise when headers are included in different orders in different source files. But that header file should be explicitly included by each source file; there should be no magic.)
Forget the compilation speed-up - a precompiled header with templates isn't really "precompiled" except for the name and the parse, as far as I've heard. I won't believe in the compilation speed up until I see it in the benchmarks. :)
As for the usefulness:
I prefer to have an IDE which handles my includes for me (this is still bad for C++, but Eclipse already adds known includes with ctrl+shift+n with... well, acceptable reliability :)).
Doing 'clandestine' includes like this would also make testing more difficult. You want to compile a smallest-possible subset of code when testing a particular component. Figuring out what that subset is would be difficult if the headers/sources aren't being honest about their dependencies, so you'd probably just drag your my_cpp_std_lib_hack into every unit test. This would increase compilation time for your test suites a lot. Established code bases often have more than three times as much test code as regular code, so this is likely to become an issue as your code base grows.
From the GCC manual:
-include file
Process file as if #include "file" appeared as the first line of the
primary source file. However, the
first directory searched for file is
the preprocessor's working directory
instead of the directory containing
the main source file. If not found
there, it is searched for in the
remainder of the #include "..." search
chain as normal.
So what you're doing is essentially equivalent to starting each file with the line
#include "my_cpp_std_lib_hack"
which is what Visual Studio does when it gathers up commonly-included files in stdafx.h. There are some benefits to that, as outlined by others, but your approach hides this include in the build process, so that nobody who looked directly at one of your source files would know of this hidden magic. Making your code opaque in this way does not seem like a good style to me, so if you're keen on all the precompiled header benefits I suggest you explicitly include your hack file.
You are doing something very wrong. You are effectively including lots of headers that may not be needed. In general, this is a very bad idea, because you are creating unnecessary dependencies, and a change in any header would require recompilation of everything. Even if you are avoiding this by using precompiled headers, you are still linking to lots of object that you may not need, making your executable much larger than it needs to be.
There is really nothing wrong with the standard way of using headers. You should include everything you are using, and no more (forward declarations are your friends). This makes code easier to follow, and helps you keep dependencies under control.
We try not to include the unused or even the rarely used stuff for example in VC++ there is
#define WIN32_LEAN_AND_MEAN //exclude rarely used stuff
and what we hate in MFC is that if u want to make a simple application u will produce large executable file with the whole library (if statically linked), so it's not a good idea what if u only want to use the cout while the other no??
another thing i don't like to pass arguments via command line coz i may leave the project for a while, and forget what are the arguments... e.g. i prefer using
#pragma (comment, "xxx.lib")
than using it in command line, it reminds me at least with what file i want
That's is my own opinion make your code stable and easy to compile in order to to rot as code rotting is a very nasty thing !!!!!