Where do you place your #includes?
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
If a header file depends for its compilation on another header file, the second header file is included in the first.
// header1.h
// depends on contents of header2.h for compilation
#include "header2.h"If a source file depends for its compilation on a header file, that header file is included in the source file.
// source.c
// depends on contents of header1.h for compilation
#include "header1.h"In your case, <windows.h> is needed only in the source file, so it is included only there. Note that this also helps porting - the header file (which is O/S-independent) does not need changing, but the source file (which is O/S-dependent) does. I admit that my method could cause a file to be included multiple times. This is not as big a problem as it used to be: 1. Modern compilers often cache header files 2. SSDs are much faster than HDDs
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
I try to avoid this now as I have run into situations when I get compile errors due to circular references in which one include is depending on another include file. These errors can be hard to find especially with a large project. This is not so much an issue with MFC includes as it is with my own project includes. So I put the includes in the .c or .cpp file.
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
I tend to (loosely) follow the guideline: if the file (header or source) doesn't need an header then it should not include it. Speeding up compilation is more an issue with
C++than withC(passing fromC++toCis the real performance boost on compilation times, in my experience). -
I tend to (loosely) follow the guideline: if the file (header or source) doesn't need an header then it should not include it. Speeding up compilation is more an issue with
C++than withC(passing fromC++toCis the real performance boost on compilation times, in my experience).That's what I thought... I've been doing it mostly wrong for 7 years :doh: Thanks!
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I try to avoid this now as I have run into situations when I get compile errors due to circular references in which one include is depending on another include file. These errors can be hard to find especially with a large project. This is not so much an issue with MFC includes as it is with my own project includes. So I put the includes in the .c or .cpp file.
speedbump99 wrote:
circular references in which one include is depending on another include file. These errors can be hard to find especially with a large project.
Bumped into them, they are quite the PITA to debug. It took me a while to understand how to do things properly... My only excuse is that the project I've worked on for 7 years was a horrible misture of global variables, global functions and poorly designed (damned self-taught programmers) C++ classes.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
If a header file depends for its compilation on another header file, the second header file is included in the first.
// header1.h
// depends on contents of header2.h for compilation
#include "header2.h"If a source file depends for its compilation on a header file, that header file is included in the source file.
// source.c
// depends on contents of header1.h for compilation
#include "header1.h"In your case, <windows.h> is needed only in the source file, so it is included only there. Note that this also helps porting - the header file (which is O/S-independent) does not need changing, but the source file (which is O/S-dependent) does. I admit that my method could cause a file to be included multiple times. This is not as big a problem as it used to be: 1. Modern compilers often cache header files 2. SSDs are much faster than HDDs
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
I admit that my method could cause a file to be included multiple times.
Not a big problem because widely used headers should be put into precompiled headers if compilation time is important. Thank for sharing your modus operandi.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
That's what I thought... I've been doing it mostly wrong for 7 years :doh: Thanks!
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
I never put includes into a header file if I can avoid it using forward declarations. Any source code file including that header then can decide for itself whether it needs (and must include) the full declaration. There's no benefit to put includes into headers other than saving a little typing in your source files that may need some more include statements than usual. (and you could actually reduce or avoid that if you just put commonly used headers in your .PCH file instead) But there's a high risk in doing so: macros breaking other source files (e. g. the min and max macros #defined when including windows.h breaking STL code); the global name space cluttered with thousands of symbols that may conflict with local names; and compilers silently resolving a function call to something different than you expect because of such conflicts. There are several benefits to avoiding includes in headers, such as reducing response times of any tool or functionality that requires parsing your code (including your language-sensitve text editor and compiler), and avoiding unnecessary clutter in your global namespace. It's also informative to see what the declarations inside of a header (or source) file really depend on.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
I used to place all my #include directives in the header files, for two reasons: 1) When using C++ I have classes to derive to and from, therefore my derived class must "know" its ancestors; 2) I like to use the header files as indexes of the source files: the information about which dependencies has a module is more useful in the header file, as I don't even have to look at the source code unless there are troubles. I don't mix and match, so I always put all my #includes in the header file. Now I'm using plain C for a project and I had to include a bulky header (<windows.h> in this instance) to access an API needed only inside that .c file (the rest of the code doesn't use windows APIs). This made me doubt about the soundness of the choice of putting all #include directives in the header file: having the inclusions constrained in their own compilation units would speed up compilation time and create more separation between modules; on the other hand complex structures often include dozens of headers and the lower levels would benefit from the inclusions already managed by its dependancies. What do you think about this issue? How do you normally operate?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
I am going to disagree with almost all above in C the standard industry practice is the only time a header is declared in the header file is if an actual interface call requires a type in the header. There simply is no other valid reason you should ever do it because of caching blah blah blah others mentioned. The basic premise is why would you want a dependency on the interface at compile time if the interface doesn't need to know the dependency. The header is there as clean interface segmentation layer not somewhere for you to play around with speed ups and your own personal playground. Internally in the C file if your C code requires the header declare it in the .c file again because it is required!!!!!! Basic rule you never include anything in any file that is not absolutely required .... that is the end of the story. I am anal and actually record why I am including the unit with a comment... so this is a typical example
#include // C standard unit needed for bool and true/false
#include // C standard unit needed for uint8_t, uint32_t, etc
#include // C standard unit needed for variadic type and functions
#include // C standard unit needed for strlenSo on your example I would never declare windows.h in my unit header unless I had a function in the C file that needed the interface to pass a windows type again I would comment why the header is included and as an example
#include // Windows standard header needed for HWND on calls
void MyUnitFunction (HWND window);
If I had the situation no public interface needed internal windows types (they were just using normal c types etc) the #include would only ever be in the .C file and not the header file as I don't need to tell the interface. So for me no includes don't always go in the header files or in the C files they go where they are absolutely required !!!!!!! You should find that alone will stop lots of stupid circular problems you would get otherwise. If you have two units that go circular and you really can't organize them better then as already mentioned above in one unit forward declare the other units interface functions. Generally you choose the one with the least functions to forward.
In vino veritas
-
I try to avoid this now as I have run into situations when I get compile errors due to circular references in which one include is depending on another include file. These errors can be hard to find especially with a large project. This is not so much an issue with MFC includes as it is with my own project includes. So I put the includes in the .c or .cpp file.
No Problem at all: #ifndef HEADER_XY #include 'HEADER_XY.H' #endif In HEADER_XY.H must - of course - written been #define HEADER_XY
