The question is about including an unnecessary header to avoid calling it multiple times in sub-files.
Here's the scenario, I have a few files:
srlogger.h
srinterface.h
srinterface.cc
#include <srinterface.h>
#include "srlogger.h"
srbinhttp.h
#include "srinterface.h"
srbinhttp.cc
#include <srbinhttp.h>
#include "srlogger.h"
srsocket.h
#include "srinterface.h"
srsocket.cc
#include <srsocket.h>
#include "srlogger.h"
srhttp.h
#include "srinterface.h"
srhttp.cc
#include <srhttp.h>
#include "srlogger.h"
Now, what I want to do is to remove the #include "srlogger.h" from all .cc files shown, and instead include it to the srinterface.h file as:
srinterface.h
#include "srlogger.h"
Since all of the .cc respective header files include the srinterface.h the srlogger.h would be covered.
Now, why would this be bad?
Please do not say that you should only include the necessary headers to compile and nothing extra, this is not enough explanation.
I want to know in real examples why this would be bad.
Oh if someone removes the #include "srlogger.h" from the srinterface.h it would break the other file, this is a weak explanation. A comment after the include could easily warn other people.
What interests me the most is if it will affect the compilation in a bad way, will the size of the objects or executable files change because of that, does it affect performance.
Or you have a really good explanation why this is bad.
PS.: If you are curious why would I want to do that, is because I was mapping the dependencies between the files, and doing such a thing I can create a graphical visualization between all the dependencies, making it easier to understand how the pieces of the puzzle fit together. Transferring sub-headers to common header in the higher hierarchy header creates a more organized structure between the all files.
The potential negative effect is one of compile time. If someone includes your header who doesn't need the header it drags in, the compile time of that compilation unit will increase for no good reason.
For toy projects or small projects (of a few hundred files) that compile in a few seconds, this makes no real difference.
But when you work on projects that are millions of lines of code spread across hundreds of thousands of files, that already take a significant fraction of an hour to compile, and you add an include to a header that's included by 12000 other files because you could not be bothered to explicitly add it to the 120 files that actually needed it (but just happened to include the common header) - then you are not going to be popular, since you just increased everyones average build time by several minutes.
There is also the risk (in bad code bases) that the header you (unnessesarily) drag in to other files may redefine stuff that breaks things for that source file that didn't even need the other header in the first place.
For the above reasons, I believe that headers should only include what they really need themselves and cannot forward declare. Implementation files should only include headers they really need (and include their own headers first to make sure they are self contained).
Hope that answers your question.
"The question is about including an unnecessary header to avoid calling it multiple times in sub-files."
Include guards will solve the feasible part of this problem of including multiple headers in the same file. Include guards will cut down the unnecessary includes to a certain extent. See the link below:
C++ #include guards
An include guard is made by adding the following to your header file:
//at the very top of the header
#ifndef NAMEOFHEADER_H
#define NAMEOFHEADER_H
// header info
//at the very last line of the header
#endif
This will keep you from accumulating the same header file multiple times in another .h or .cpp file.
And as was stated in the comment below, even if every header has include guards you can still end up with information not even needed for your file being defined by the compiler during its preprocessor directives. This is bound to happen with the chain of includes across multiple files.
Related
I have been placing my #include statements in the header file, then only including the header in main to make my main file look cleaner. However, every other C++ code I look at leaves them in main. Does it make a difference either way? If it does, why?
Example:
Header:
#pragma once
#include <iostream>
#include <string>
#include <iomanip>
#include <fstream>
using namespace std;
class Question
{
private:
Main:
#include "Header.h"
int main()
{
There are a few considerations:
you want to minimize header inclusions because they slow down the builds, and increase the dependency tree. Code that includes your header depends on every header it includes, and every header that they include, and so on, all the way down. Suppose a some user includes your header, and you include 20 other headers in it, then
any time any of those headers you include changes, the client code has to recompile
client code has to parse all those headers every time it builds.
The real problem is the multiplying effect: you get slower builds that also have to be done more often (because the number of files depended on goes up.) This is partly why c++ projects are so slow to build. Some headers contain substantial amounts of complex template code, and it gets compiled over and over, for each translation unit that it appears.
The fewer inclusions your headers have, the less implementation detail you depend on as well. The attitude of "put lots of code into headers!" tends to make them contain more implementation detail than necessary. That is, instead of merely declaring a function, it also defines the function, then that means development work happens in the header, not the cpp file. So that makes the headers change even more often, causing everyone who includes it to need to be rebuilt for (oftentimes) no good reason.
When you keep an include isolated inside a .cpp file, then only that cpp file has the dependency on it--not your users. This helps isolate your clients from having to parse and build the headers that you use but don't need to provide.
More things included in headers also causes more names to be visible to consumer code. This can increase name collisions, create ambiguities, possibly have macros interfere, and so on. Namespaces can help, but if a user gets 100 overloads of operator<< because they include your header, then every time they need to resolve an overloaded <<, the compiler has 100x more functions to choose from to decide which one to call, which again can slow down the build. And so on.
The goal is to minimize what you expose to your users, and the header is what you expose.
Only put the minimum required #include in a .h file. That way you prevent unexpected code collisions and unnecessary make dependencies.
It only makes a difference for bigger projects. If you include a lot of headers in headers and have a lot of source files you will include headers multiple times. This can drastically increase compile times.
For small projects (~10000 lines) it is fine either way.
I recently started working on a project where I came across this:
#include <string.h> // includes before include guards
#include "whatever.h"
#ifndef CLASSNAME_H // header guards
#define CLASSNAME_H
// The code
#endif
My question: Considering all (included) header files were written in that same style: Could this lead to problems (cyclic reference, etc.). And: Is there any (good) reason to do this?
Potentially, having #include outside the include guards could lead to circular references, etc. If the other files are properly protected, there isn't an issue. If the other files are written like this one, there could be problems.
No, there isn't a good reason that I know of to write the code with the #include lines outside the include guards.
The include guards should be around the whole contents of the header; I can't think of an exception to this (when header guards are appropriate in the first place — the C header <assert.h> is one which does not have header guards for a good reason).
As long as you don't have circular includes (whatever1.h includes whatever2.h which includes whatever1.h) this should not be a problem, as the code itself is still protected against multiple inclusion.
It will however almost certainly impact compile time (how much depends on the project size) for two reasons:
Modern compilers usually detect "classical" include guards and just ignore any further #includes of that file (just like #pragma once). The structure you are showing prevents that optimization.
Each compilation unit becomes much larger as each file will be included much more often - right before the preprocessor then deletes all the inactive blocks again.
In any case, I can't think of any benefit such a structure would have. Maybe it is the result of some strange historical reasons, like some obscure analysis tool that was used on your codebase in pre-standard C++ time.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
Is it a good programming practice to have #include statements in a header file. I personally feel that, especially, when you're going through a code base someone else wrote, you end up missing or spend time looking for definitions which could have found sooner if it was in the c file.
In some (from my experience - most) cases, it's impossible to do what you say. You often end up returning various other classes from your code, and - obviously - you need to include the information about that in the function declarations. In that case, the compiller has to already know what those other objects are, so you either have to already include a header with the declaration, or provide a forward declaration.
Since you'll end up including the header anyhow, there's no real point in doing an additional forward declaration. That's of course a thing of choice, but it doesn't make your code clearer in my opinion.
Also - most of the IDE's have an option to find a symbol in the included files.
If (and only if) you're in a point when you only need classes/functions inside your definitions, then you may vote to include the header in the *.c file. It may be clear at first glance, but you may find that - when modifying the class someday - you'll end up moving the #include to the *.h file anyway.
The short answer is yes. If a particular header that is defining/declaring classes, types, structs, etc. that are composed of classes, types, structs, etc. that are defined/declared in other header files then the most expedient and effective practice is to include those header files into the header file.
By doing so, the header files that are dependencies on the header file you are creating will be there.
There may be issues of files being included multiple times which is why most header files contain either #if to ensure the file is included only once or using something like a #pragma to ensure only included once.
To sum up, you should design your header files so that if they are included multiple times by several uses of a #include of your header file that the header file will only appear once in the preprocessor output. By including the header files on which your header file depends in the header file, you localize the use of the header and make sure that any dependencies will be available.
And in addition by using the #include of dependency header files into your header file, if the include path is incorrect so that a dependency header file is not available, it will be easy to find the header which is depending on the unavailable header file.
Header files should manage their own dependencies; having to get the order of #includes in a .c file just right is an annoying way to waste an afternoon, and it will be a perpetual maintenance headache going forward. Have you headers #include whatever they need directly, use #include guards in your own headers, and life will be much easier.
It is not in bad style if it is necessary to make the header file self-contained in the sense that it does not depend on any other header being manually included. For example, if the header contains declarations that use data types from stdint.h then it should have #include <stdint.h> rather than expect everyone to include it separately, and in the correct order.
Meanwhile unnecessary #includes are generally in bad style regardless of where they are (.h or .c). Arguably an exception to this might be an entire collection of libraries that could in theory be used individually but are intended to be used as a whole, such as a complete GUI toolkit – in that case I think it's cleaner to have some master header that pulls in all the declarations rather than have the user learn which header is required for which specific function.
I prefer to not have #include in header files, if only to make the dependencies visible on one place for each source file. But that is certainly arguable.
Golden rule is readability. Silver rule is follow existing practice.
Don't #include anything you don't need.
Don't #include anything you don't need because including unnecessary files leads to unnecessary dependencies and also leads to larger compile times for larger projects. As a consequence, if you modified an existing class to replace vector with list, take an extra few seconds to look through the file and make sure you don't have any vector remnants left over, and delete the #include <vector> from the top of the file.
Use forward declarations instead of #include where possible.
Use forward declarations where possible because it reduces dependencies and minimizes compile times. A forward declaration will do if your class header does not declare an object of the class; if you only use it by pointer or (in C++) by reference, then you can get by with a forward declaration.
Use #ifdef or #pragma guards to design your header files such that they're not included multiple times.
// MyClass.h
#ifndef MYCLASS_HEADER
#define MYCLASS_HEADER
// [header declaration]
#endif // MYCLASS_HEADER
Alternatively on a supporting compiler such as Visual Studio:
// MyClass.h
#pragma once
// [header declaration]
These guards will allow you to #include "MyClass.h" as often as desired without worrying about including it multiple times in the same translation unit.
Include/forward-declare in the header if the included file is needed by the header.
If the header needs a forward declaration or to fully include the header, then doing so is a no-brainer.
Include in the .c/.cpp file if the included file is not needed by the header, but is needed by the implementation.
If the header has no use for the header--because a forward-declaration is sufficient or because only the .c/.cpp file needs it--then don't #include in the header. Remember: Push off whatever you can into the .c/.cpp file to reduce dependencies and minimize compile times.
I am reading a book on Applied C++.
Include guards will prevent a header file from being included more
than once during the compilation of source file. Your symbol names
should be unique, and we recommend choosing the name based on the name
of the file. For example, our file, cache.h contains this include
guard.
#ifndef _cache_h_
#define _cache_h_
...
#endif // _cache_h_
Lakos describes using redundant include guards to speed up
compilation. See [Lakos96]. For large projects, it takes times to open
each file, only to find that the include guard symbol is already
defined (i.e., the file has already been included). The effects on
compilation time can be dramatic, and Lakos shows a possible 20x
increase in compilation times when only standard include guards are
used.
[Lakos96]: LargeScale C++ software design.
I don't have Lakos96 reference book to refer concept so asking help here.
My questions on above text is
What does author mean by " For large projects, it takes times to open each file, only to find that the include guard symbol is already defined" ?
What does author mean by "when standard include guards are used" ?
Thanks for your time and help.
From C++ Coding Standards (Sutter, Alexandrescu)
Many modern C++ compilers recognize header guards automatically (see
Item 24) and don't even open the same header twice. Some also offer
precompiled headers, which help to ensure that often-used,
seldom-changed headers will not be parsed often
So, I would consider those suggestions outdated (unless you are still using some very dated compiler).
As for your questions:
it means: opening a file which is not needed (since it has been already included; which you will know because the include guard is already defined) is costy; and this might be an issue if you do it a lot of times (which can happen if you have hundreds of files in your project).
as opposed to using non-redundant compile guards.
What is a redundant compile guard?
A naive compiler will reload the file every time it's included. To
avoid that, put RedundantIncludeGuards around the include: header.h
#ifndef HEADER_H_
#define HEADER_H_
// declarations
#endif
foo.c
#ifndef HEADER_H_
#include "header.h"
#endif
read more here. Your reference claims that by doing so you can be as much as 20% faster during compilation than you would be if foo.c were only doing
#include "header.h"
I don't know what Lakos96 says, but I'm going to guess anyway...
A standard include guard is like:
foo.h
#ifndef FOO_H_INCLUDED
#define FOO_H_INCLUDED
....
#endif
A redundant include guard is using the macro when including the file:
bar.c
#ifndef FOO_H_INCLUDED
#include "foo.h"
#endif
That way the second time the foo.h file is included, the compiler will not even search for it in the disk. Hence the speedup: imagine a large project, one single compilation unit may include foo.h 100 times, but only the first one will be parsed. The other 99 times it will be searched for, opened, tokenized, discarded by the pre-compiler and closed.
But note that that was in 1996. Today, GCC, to give a well known example, has specific optimizations that recognize the include guard pattern and makes the redundant include guard, well..., redundant.
Lakos' book is old. It may have been true once, but you should time things on your machine. Many people now disagree with him, e.g.
http://www.allankelly.net/static/writing/overload/IncludeFiles/AnExchangeWithHerbSutter.pdf
or http://c2.com/cgi/wiki?RedundantIncludeGuards
or http://gamearchitect.net/Articles/ExperimentsWithIncludes.html
Herb Sutter, C++ guru and current chair of the ISO C++ standards
committee, argues against external include guards:
"Incidentally, I strongly disagree with Lakos' external include guards
on two grounds:
There's no benefit on most compilers. I admit that I haven't done measurements, as Lakos seems to have done back then, but as far as I
know today's compilers already have smarts to avoid the build time
reread overhead--even MSVC does this optimization (although it
requires you to say "#pragma once"), and it's the weakest compiler in
many ways.
External include guards violate encapsulation because they require many/all callers to know about the internals of the header -- in
particular, the special #define name used as a guard. They're also
fragile--what if you get the name wrong? what if the name changes?"
I think what it refers to is to replicate the include guard outside of the header file, e.g.
#ifndef _cache_h_
#include <cache.h>
#endif
However, if you do this, you'll have to consider that header guards are sometimes changing within a file. And you certainly won't see a 20x improvement in a modern system - unless all your files are on a very remote network drive, possibly - but then you'll have a much better improvement from copying the project files to your local drive!
There was a similar question a while back, regarding "including redundant files" (referring to including header files multiple times), and I built a smallish system with 30 source files, which included <iostream> "unnecessarily", and the overall difference in compile time was 0.3% between including and not including <iostream>. I believe this finding shows the improvement in GCC that "automatically recognises files that produce nothing outside of include guards".
In a large project, there may be many headers - perhaps 100s or even 1000s of files. In the normal case, where include guards are inside each header, the compiler has to check (but see below) the contents of the file to see if it's already been included.
These guards, inside the header, are "standard".
Lakos recommends (for large projects) putting the guards around the #include directive, meaning the header won't even need to be opened if it's already been included.
As far as I know, however, all modern C++ compilers support the #pragma once directive, which coupled with pre-compiled headers means the problem is no longer an issue in most cases.
in larger projects with more people, there may be, for example, one module dealing with time transformation and it's author could chose to use TIME as a guard. Then you'll have another one, dealing with precise timing and it's author, unaware of the first one, may choose TIME too. Now you have a conflict. If they used TIME_TRANSFORMATION and PRECISE_TIMING_MODULE, they'll be ok
Don't know. I would guess it coud mean "when you do it every time, consistently, it becomes your coding standard".