Quote Originally Posted by kaos_frack View Post
In large projects it's probably better to keep and update a diagram of header/source files with their relationships even if the developers(s) can remember everything, because other people who read the code might get confused. Ideally a project should already have that kind of a diagram before even starting to code IMHO.
Thank you all
This presumes that certain headers and implementation files somehow "belong" together. The purpose of a header file is to define an API.

The way to reduce confusion about headers is to:

1) Make your libraries/APIs as cohesive as possible

2) Only require a single header to access a given library/API, even if this is implemented "under the hood" as multiple headers

3) Make the name of the header correspond to the name of the library/API so people don't have to guess what file to include

It is tempting to create many smaller header files in an effort to reduce some imaginary compilation cost. That's definitely premature optimization.

And to address the original question more specifically, if you need some declaration X, and it's declared in X.h, then you should include X.h. Even if you've already included some other header which you know includes X.h.