When do you need to use #include in c++

Question

I've been programming for awhile now and one thing I've still never quite figured out is exactly when you need to #include something. I know to be safe you can do it whenever you use something declared in another file. However at times I find that I can remove an #include and everything will still compile just fine. From what I can tell this is because other files being included already are including the external definition. There are two particular cases I'm interested in knowing the behavior for:

1. Say we have three .h/.cc pairs: f1.h/.cc, f2.h/.cc, and f3.h/.cc. If f2.h/.cc includes f1.h and f3.h/.cc includes f2.h is it ever necessary for f3.h/.cc to include f1.h or will all of f1.h's definitions be visible to the f3 files when it is included in f2?

2. Once again say we have three .h/.cc pairs: f1.h/.cc, f2.h/.cc, and f3.h/.cc. If f2 includes f1 and f2 includes f1 and then f3 includes f1 or f2 will the "circular linkage" between and f1 and f2 cause a problem?

Do you know of any good resources online I can read to better understand how including something in one file affects subsequent files in the project?

Answer 1

There is nothing much to it. If you use something, you have to include the header declaring the thing you use. About the only exception is forward declaring a class/struct or method like:

class myclass;   

if you just need to declare a pointer or reference to the class.

You cannot really rely on other headers including the header you need, by chance. Any day, the maintainer of the other header will realize that he/she don't need that include anymore and remove it.

Answer 2

Question 1: I think all you're missing is the difference between "f2 includes f1", and "f2 is guaranteed to include f1". This is particularly important with standard headers, since any standard header is allowed to include any other. So if you rely on indirect includes that work on your machine, then your code might fail to compile on a different C++ implementation.

If you have a library where the documentation for "f2.h" says or implies that it includes "f1.h", that means it always will in all compatible versions, so then you can rely on the indirect include. You might do this where you're using one component of a library that fundamentally relies on another component of that library, but where the other component might be used in isolation by other users. For a hypothetical example, "xhtml_parser.h" might reasonably document that it provides all definitions from "xml_parser.h", plus some extra ones.

Question 2: Um, would you like to rephrase the question? "f2 includes f1 and f2 includes f1" isn't what you meant, and there is no "circular linkage". It can cause problems if you write headers such that f1 includes f2 and f2 includes f1, because include isn't "linkage", it's pretty much a cut and paste of the contents of the other header file.

So even before f3 come into the picture, circular includes can be problematic:

f1.h
----
#ifndef f1_h_included
#define f1_h_included

#include "f2.h"
struct DerivedA : BaseA {};
struct BaseB {};

#endif

f2.h
----
#ifndef f2_h_included
#define f2_h_included

#include "f1.h"
struct BaseA {};
struct DerivedB : BaseB {};

#endif

This isn't going to compile no matter which you include of "f1.h" and "f2.h". Assuming f1 is included first, the result after preprocessing looks like this:

// contents of f2.h, pasted in at line 4 of f1.h
// (contents of f1.h on the circular include are ignored due to include guard)
struct BaseA {};
struct DerivedB : BaseB {};

// rest of f1.h
struct DerivedA : BaseA {};
struct BaseB {};

And so DerivedB specifies a base class which has not yet been defined. Include them the other way around, same problem with DerivedA.