Include whole module vs include specific headers

[Oldie]

I would like to know what I can gain from including specific SFML headers in each of my own header files (like <SFML/Graphics/Sprite.hpp>, <SFML/System/Clock.hpp>), instead of simply including <SFML/Graphics.hpp> everywhere in the case of an application using 2D graphics?

• Can my executable be lighter if, after all headers are included from everywhere, some SFML header files are not called for?
• Can the application be faster?
• Can it take less RAM?
• Anything else?

I usually link dynamically, but the question also holds for static linking.

Sorry for what may appear to be noob questions. All the building process is not what I prefer in coding.

[Ixrec]

Because compilers aren't stupid, any code you don't actually use in your program will never appear in your executable anyway.  So most of those questions are a very easy "no" if you're compiling SFML and your program together (I believe statically linking binaries works the same way).  Of course, if you're using the SFML dynamic libs or compiling SFML separately from your program, then the unused code will still be in the binaries/libraries regardless of what headers you include.  And no matter what you do, SFML is a small enough library I'd be shocked if there was any serious difference in speed or RAM usage or whatever.

The only difference this is likely to make is reducing compile time, because the compiler doesn't have to check all the other headers in your module just to discover you don't use any of them.  I think it's unlikely you'd gain enough to justify the nuisance of tweaking your headers all the time, but feel free to try it.

[Nexus]

The only difference this is likely to make is reducing compile time, because the compiler doesn't have to check all the other headers in your module just to discover you don't use any of them.  I think it's unlikely you'd gain enough to justify the nuisance of tweaking your headers all the time, but feel free to try it.

In bigger projects, or especially in libraries, you should really care about what you include, because it can make a notable difference. Keep in mind that SFML may also include a lot of standard library headers that you don't need. Doing this in loads of .cpp files may lead to an unnecessarily slow compilation process. #include <SFML/Graphics.hpp> and the others exist primarily for experiments and smaller projects where compile time is not a concern.

The other advantage is that you see at the beginning of a file which classes and functions the header or implementation file requires, so it can give you a rough idea about the dependencies.

[eXpl0it3r]

Including only specific headers does to my knowledge not have any impact on the final binary or its execution.

The two main reasons in general that I can think of are:

• Drastically reduce compile time. It might not have a huge impact with only SFML headers, but as soon as you start adding a few dependencies, you'll notice it quickly. It's also why you can #define some things to reduce the header inclusions in windows.h header.
• With only specifying the actually used headers, you can understand what a class is depending on just by looking at the include section.

When I'm simply writing something together, I usually just use the module headers or often just the Graphics header, but for "actual" projects I try to only include the needed headers.
For SFML only the gain is however quite low.

[Oldie]

Thanks for the answers!

I replaced #include <SFML/Graphics.hpp> by all the SFML header files explicitely needed in every header file of my own.
SFML header files include one another, but I did not take that into account. Eg., Font.hpp already includes Texture.hpp, both files I explicitely include in my asset manager header file. I do not know if better can be done.
Compilation speed is about the same: around 1 second for each file, so any difference is hardly noticeable. But it surely does tell about existing dependencies, which could be useful for future design optimization.

[eXpl0it3r]

SFML header files include one another, but I did not take that into account. Eg., Font.hpp already includes Texture.hpp, both files I explicitely include in my asset manager header file. I do not know if better can be done.

That's the correct way, you can't rely on what thirdparty headers include, because that may change at any time.

Btw. make sure to include as much as possible as late as possible, i.e. load as many headers in the source file as possible. If you're only using a reference or a pointer of a class, use foward declaration and include the class header in the source fild.

[Nexus]

Compilation speed is about the same: around 1 second for each file, so any difference is hardly noticeable.

There are some headers which have a lot of dependencies on their own, so it will be difficult to notice.

What also has to be taken into account, is that standard library headers take rather long to parse, because they use loads of templates (for Boost, it's even orders of magnitude worse). Thus, if you can avoid including a SFML header with its <vector> and <map> includes, that may already make a difference.

But don't exaggerate just to get some milliseconds; if you follow eXpl0it3r's advice of only including the necessary headers, it should compile fast enough. When you get into problems, the Pimpl idiom is also an option to reduce compile-time dependencies.