Convention for which source file to put your includes
This is a question about convention I think since it seems it does not matter where you put your include declaration (your header file or your c source file?)
Ok so suppose you need to include someheader.hpp in mysource.cpp.
Suppose you also have a mysource.hpp to go with it.
Where do you put your #include "someheader.hpp"? In mysource.cpp or mysource.hpp?
I ask because I am working on a big project with lots and lots of source files and header files.
Right now there seems to be no rule on where to put your preprocessor directives (include files mostly). I'd like to get this figured out because its sort of messy to go looking around between header and source files see what is included in big projects.
Ok so suppose you need to include someheader.hpp in mysource.cpp.
Suppose you also have a mysource.hpp to go with it.
Where do you put your #include "someheader.hpp"? In mysource.cpp or mysource.hpp?
I ask because I am working on a big project with lots and lots of source files and header files.
Right now there seems to be no rule on where to put your preprocessor directives (include files mostly). I'd like to get this figured out because its sort of messy to go looking around between header and source files see what is included in big projects.
Depends on which file uses "someheader.hpp." I'm not 100% sure what .hpp files are, but I'm guessing they are similar to .h files?
Anyway, you may have to #include it in both "mysource.cpp" and "mysource.hpp" if both of them use it. If just one of them uses it, then just include it in that one.
Anyway, you may have to #include it in both "mysource.cpp" and "mysource.hpp" if both of them use it. If just one of them uses it, then just include it in that one.
hpp is h file. It was pushed for mildly a long time ago, and never really took on with the general population. It serves no purpose unless you mix c and c++ and need to differentiate.
I put stuff as close to where it is needed as I can, in the h files.
that is if mysource needs someheader, then mysource.h includes someheader.h. That is not the only way to do it, but it is how I do it. The reason is that I look at headers when I want to use someone else's code, rarely the .cpp. The include in the header tells me what the thing I wanted depends on, its not hidden in a cpp file.
there are other ways, though, as I said. As long as it works, its fine. Just be careful with include guards and order of includes, both can trip you up.
I put stuff as close to where it is needed as I can, in the h files.
that is if mysource needs someheader, then mysource.h includes someheader.h. That is not the only way to do it, but it is how I do it. The reason is that I look at headers when I want to use someone else's code, rarely the .cpp. The include in the header tells me what the thing I wanted depends on, its not hidden in a cpp file.
there are other ways, though, as I said. As long as it works, its fine. Just be careful with include guards and order of includes, both can trip you up.
Last edited on
Here's the approach I try to use:
- All files should include their dependencies. A user who includes x.hpp shouldn't need to include anything prior to x.hpp in order to successfully compile. This practice shrinks long lists of #include directives and eliminates a minor maintenance burden involved in updating those lists.
- Header files define an interface, and should include nothing besides what's needed to use (not define) the interface. This practice can substantially shorten builds. Some programmers really care about build speed.
- Order every inclusion in decreasing order of specificity. Within x.cpp include x.hpp first, followed by private headers, followed by everything else. This practice helps ensure that header files are actually stand-alone.
- All files should include their dependencies. A user who includes x.hpp shouldn't need to include anything prior to x.hpp in order to successfully compile. This practice shrinks long lists of #include directives and eliminates a minor maintenance burden involved in updating those lists.
- Header files define an interface, and should include nothing besides what's needed to use (not define) the interface. This practice can substantially shorten builds. Some programmers really care about build speed.
- Order every inclusion in decreasing order of specificity. Within x.cpp include x.hpp first, followed by private headers, followed by everything else. This practice helps ensure that header files are actually stand-alone.
Last edited on
| Right now there seems to be no rule on where to put your preprocessor directives (include files mostly). I'd like to get this figured out because its sort of messy to go looking around between header and source files see what is included in big projects. |
Only include a header file A.h within header file B.h if B.h uses a definition from A.h. What if
B.h unnecessarily includes A.h, and B.h is included in B.cpp, X.cpp, Y.cpp, Z.cpp, AA.cpp, etc. If you make a change to A.h, then X.cpp, Y.cpp, Z.cpp, A.cpp, etc. will need to be recompiled for no reason. If only B.cpp requires the definitions within A.h, then put the #include "A.h" statement in B.cpp.
I don't know what you mean by a "big" project, but to me a "big project" can take hours to build. Placing your header files in other header files (when not needed there) can turn a 10 minute rebuild into a 2 hour lunch break.
So, the answer to your question is, put the header files as close to where they are needed as possible. Put them in the .cpp files unless they are needed in the header file.
Also, your compiler almost certainly has an option for producing a dependency list, so you don't have to trace through manually to figure out what is included in any particular compilation unit.
@agentmax I am a stickler, .h = C lang, .hpp=C++ lang. I come from C mostly and thinking about .h files with namespaces for example makes me want to barf. So I still push for .hpp for C++. C stuff works in C++ stuff but not the other way. That said, ASSEMBLY works in C and in C++. Just backwards compatibility, but I would not name a source file .asm with C++ code even though it will probably compile. But I digress.
So then @jonnin would it look odd to have virtually no #includes in your source file if you have a header file for it?
@mbozzi makes sense to me. So from what I understand, if mysource.cpp is doing something for itself and needs something.hpp, there is no need to #include something.hpp in mysource.hpp, only put it in mysource.cpp. Basically if there is no reason to create an interface for something, no need to include that something in the header file, only in the source file. If I understood that correctly then it makes a lot of sense! Thanks.
So then @jonnin would it look odd to have virtually no #includes in your source file if you have a header file for it?
@mbozzi makes sense to me. So from what I understand, if mysource.cpp is doing something for itself and needs something.hpp, there is no need to #include something.hpp in mysource.hpp, only put it in mysource.cpp. Basically if there is no reason to create an interface for something, no need to include that something in the header file, only in the source file. If I understood that correctly then it makes a lot of sense! Thanks.
.hpp file would usually be a header file that includes code (such as a templated function) rather than just declarations (as .h file). But this is just 'some convention'. include files can have any extension.
Just to clarify, I personally use the extension hpp for all C++ headers. No matter their contents. Not saying this is right or wrong, YMMV.
Last edited on
So then @jonnin would it look odd to have virtually no #includes in your source file if you have a header file for it?
I think it looks great :)
it may take some getting used to, though.
every source file should probably have a header even if it does little -- surely the code has at least one class, function, or something public exposed that needs to be used somewhere?
Not every header needs a source, though.
I think it looks great :)
it may take some getting used to, though.
every source file should probably have a header even if it does little -- surely the code has at least one class, function, or something public exposed that needs to be used somewhere?
Not every header needs a source, though.
Last edited on
Topic archived. No new replies allowed.