CODEWITHSUNDEEP
c
user2568508
user2568508

Reputation:

ways to include many header files

Recently I came across code which handled header files this way. There would be one header file called say global.h This global.h would include some other header files, e.g.,

#include "settings.h"
#include "math.h"
#include "somelibrary.h"
#include "someOtherlibrary.h"
...

Now, whenever some file wanted to include say somelibrary.h, instead of writing #include somelibrary.h it would just include global.h. So each source file in the project just had: #include "global.h"

Is this common way to avoid writing many includes in each source file? what are other benefits

ps. extra: it would be nice if someone could explain why this works

Upvotes: 3

Views: 303

Answers (3)

Lundin
Lundin

Reputation: 213810

This is a commonly used bad practice. If you use a global.h, you create a tight coupling between that file and every module in the project, which in turn creates a tight coupling between every single module of your project.

That is very bad OO design! You want each module to be autonomous and only depend on other modules that are actually crucial for its own functionality. Further more, you will always want to design modules so that they can be used in several projects.

For example, if I want to use your generic math library module, which you have already developed for a particular project, then why on earth would you force me to include every other unrelated file from that project as well?

As for "avoid writing many includes in each source file"... It is completely beyond me how having to write 5-10 very short lines of text at the top of a file can be a major obstacle to a programmer. Apparently there are plenty of people who find that to be such an obstacle, that they decide to change the whole program design because of it. If you don't like typing on the keyboard, then maybe don't go for a programmer career.

Upvotes: 3

user694733
user694733

Reputation: 16043

Only benefit is the ease of including.

Downside is that everytime you make change to a header file, you have to re-compile everything. For any larger project this is a big deal.

It also makes removing or changing existing modules a pain, because you cannot do simple search for specific include to have an overview of where it is used.

Just don't do it.

Edit:

To clarify: It's OK to group headers in one if they are needed to do X. However I have rarely need to do this in practice; writing #include "xxxxx.x" is not too hard.

It's not OK to have one header with everything in it for entire application which does X, Y and Z.

Upvotes: 4

PMF
PMF

Reputation: 17185

Edit: This answer refers to the case when the include files come from different projects

As long as the include files are referring to other projects or libraries (as opposed to header files of the same project), I'd call it a reasonable way of straightening out the includes. With the "precompiled header" support from Microsoft Compilers, there's even a big performance benefit in doing so. It also ensures you're always including the headers in the same order, because this could sometimes lead to strange errors if two includes internally depend on each other.

The preferred way of creating so called "standard include headers" for MSVC is to have one file (usually named "stdafx.h"), which contains the header files of all the libraries the project is going to use, namely windows.h, math.h, io.h or string. With the correct compiler settings, all the includes that are mentioned in "stdafx.h" are only processed once for the whole project. Since these files hardly ever change, the fact that changing them requires rebuilding the whole project is not an issue. The line with #include "stdafx.h" must be the first in every c or cpp file, though. ASFAIK, gcc has no equivalent for this.

Upvotes: 1

Related Questions