Including Standard Library Headers Once in C++

ccode-quality

I am writing a program with multiple headers and code files, as so:

message.h
message.cpp
option.h
option.cpp
main.cpp

message.h includes option.h as message.cpp requires the definition of the class defined therein.

There are quite a few other files, however just to keep it brief…
If I want to call a function such as memcpy, I include string.h. I include string.h in message.h – so it works fine in message.cpp, but if I want to use it in option.cpp it gives me an error.

So I see two options:

In option.h, I include message.h again. This should not be an issue as I have include guards in both header files, however I feel it's rather messy.
I include string.h in option.h. Now I am including string.h in both of my header files.

This gives me the declaration for memcpy and so I can get on with my programming. However when I'm including 10 different headers for many different functions, it's going to be messy again.

What is a good way for me to structure my code to get around this issue, to keep my code as neat as possible? It has crossed my mind to make all my includes in one separate file and include that in all my header files, could this be a problem in the future, and is there a better way I can go about this to ensure my code is maintainable?

Best Answer

It's perfectly fine to #include additional headers in .cpp files that are not included in the corresponding .h. In fact, you should always do so if the header is not required in the .h, because that potentially speeds up compilation of anything that depends on your .h but not on your .cpp. See this classic Guru of the Week for some tips on minimizing unnecessary #includes in your header files (I don't think any of them have gone out of date yet).

In general, you should avoid relying on what other files do or don't include as much as possible, since that makes your code more modular (and more portable to other standard libraries). That means every file should explicitly and directly #include every header that it needs to know about (I'm assuming every header file has #include guards or an equivalent like #pragma once, since not having those is a far bigger problem). If the message.h author decides to follow that GotW I linked and cut down their superfluous #includes, it would be awfully frustrating if he unknowingly broke option.h/.cpp in the process. At work we once discovered some of our code would compile under GCC but not Clang solely because we were missing a few standard library #includes, and thus unknowingly depended on the fact that certain GCC headers #included each other.

So the direct answer to your original question is: You should directly include string.h in every file you plan on using it, and no others. Assuming you aren't using memcpy() inside option.h (that seems unlikely), that means the #include belongs in option.cpp.

Related Solutions

C++ – Splitting and hiding headers in a static library

You can do the following:

split the code into one class per header file.
in the case of templates, the implementation of the class functions can/should reside in the same header file (there is probably no scenario when you will want include the header, but not those definitions).
dependencies (your AuxiliaryClassK) should be #included instead of being defined directly. This makes your headers smaller, promotes code reuse (as you can include them - and only them - elsewhere) and keeps your code cleaner.
split your code into directories. The directory structure is normally a matter of policy; You could use your impl folder idea, or (for example) you could group them like boost does (one directory per functional area with all the implementation files, and one include file for convenience, which you can include in a single line in client code).
use pimpl idiom to minimize compile times.

As a rule, I would not use _Class file names. They are unusual (you increase the WTF/LOC measurement of your code which is never good).

C++ – Enforcing Manual Inclusion of Specific Header Files

Ok, I would never in a million years do this, but you could do something like this:

Force auto inclusion of this:

// forcebanned.h
#define for "You must include banned.h"

Then add this:

// mybanned.h
#undef for
#include banned.h

But don't do that. Better is to make the inclusion of banned.h a coding standard, and rely on code reviews to catch it.

If you are really insistent on enforcing this technically, you could have a custom build step that grep'd files for "banned.h" prior to compilation, failing the build if the line isn't found. (Or use some static analysis tool that tags deprecated functions.) Doing so as part of the build keeps your code simpler, and more portable.

Best Answer

Related Solutions

C++ – Splitting and hiding headers in a static library

C++ – Enforcing Manual Inclusion of Specific Header Files

Related Topic