0

Say, for example, that I have header files foo.h and bar.h, which both want to include hello.h, and use macros declared in hello.h. foo.h also already includes bar.h.

Should I include hello.h in both foo.h and bar.h, or just in bar.h? I know it doesn't matter functionally, but I'm not sure what the "standard" is for readability.

Edit: I know how header guards work. I'm not asking from a dependency perspective; I'm asking from a readability perspective.

Jonathan Park
  • 1
  • 3
  • see this post https://stackoverflow.com/questions/30873206/header-file-included-only-once-in-entire-program – Junius L Dec 20 '17 at 22:15
  • 4
    Always include the immediate dependencies. – Eugene Sh. Dec 20 '17 at 22:15
  • I think it would be better to include hello.h in both foo and bar. That way if someone is reading that one file, they can easily see that a given function comes from hello.h. – ventsyv Dec 20 '17 at 22:17
  • 1
    A header file includes another header file if it needs macros or data types defined there. There is very rarely a need for a header file to access function declarations. – AlexP Dec 20 '17 at 22:19
  • 3
    Each header file should be self-contained -- usable without needing any other headers included prior to it. That's the way the standard C headers work; yours should too. (These days, that applies to POSIX too; there's no longer any need to include `` separately.) Each header should also be idempotent; there shouldn't be any problem if the header is included multiple times. Compilers are pretty good about handling this. Use include guards. – Jonathan Leffler Dec 20 '17 at 22:26
  • To emphasize what AlexP wrote: what do you mean by "use functions declared in hello.h"? Your header file should not be defining functions, so in what way are you using functions declared in other headers? – William Pursell Dec 20 '17 at 22:38
  • I clarified: I meant macros, though it's not impossible to use function declarations inside a header file. @JonathanLeffler Not sure if your comment applies here...? I'm asking from a readability perspective. – Jonathan Park Dec 20 '17 at 22:40
  • Look up IWYU — Include What You Use. It's a Google project. What I said covers most of what you need to know. If code that uses `foo.h` must have `bar.h` available (that is, `foo.h` itself uses information from `bar.h`, whether types or macros — it probably isn't functions that are used), then `foo.h` should include `bar.h`. If the application code uses functions (types, macros) declared in `bar.h`, it should include it; if it uses functions etc from `foo.h`, it should include that, separately, even though it also includes `bar.h` (but not if it doesn't directly use functions from `bar.h`). – Jonathan Leffler Dec 20 '17 at 22:49
  • You can find a lot of my views on this general topic in my answer to [Should I use `#include` in headers?](https://stackoverflow.com/questions/1804486/should-i-use-include-in-headers/1804719#1804719). You might find some useful discussion (and useful x-refs) in [Is `#define` banned in industry standards?](https://stackoverflow.com/questions/34496418/is-define-banned-in-industry-standards/34496517#34496517), though that's primarily about `#define` rather than `#include` per se. – Jonathan Leffler Dec 20 '17 at 22:55
  • Helpful as your information is, I already know how the preprocessor works and it's not answering the question. – Jonathan Park Dec 20 '17 at 22:58
  • I'm sorry it's not helpful to tell you what you need to know. You need to make headers minimal, self-contained, idempotent. If you make them so, you will know what you need to do. Maybe [How to link multiple implementation files in C](https://stackoverflow.com/questions/15622409/how-to-link-multiple-implementation-files-in-c/15622496#15622496) will help (it covers aspects of header file design); maybe [How to structure `#include` in C?](https://stackoverflow.com/questions/276386/how-to-structure-includes-in-c/276588#276588) will help. Maybe you don't need help since you already know. – Jonathan Leffler Dec 20 '17 at 23:02
  • When you say "minimal" is that a yes or no to my question? Please read my question again. I'm not asking how to deal with dependency issues--I'm asking if knowingly putting an unnecessary include would be useful down the road for readability. – Jonathan Park Dec 20 '17 at 23:09
  • 1
    How would including an "unneccessary" include help readability? `#include ` seemingly does nothing to help understand later code. – Andrew Henle Dec 20 '17 at 23:14
  • It's unnecessary in the sense that I know that since foo.h includes bar.h, and bar.h includes hello.h, I don't need to include hello.h in foo.h. However, hello.h is an immediate dependency. Thank you @EugeneSh., and that does make the most sense. Seems that's the consensus. – Jonathan Park Dec 20 '17 at 23:17

1 Answers1

0

You can wrap the header into preprocessor-ifs. So the compiler will handle it if you include them to often.

#ifndef _MYHEADER_
#define _MYHEADER_

// whatever

#endif
chris01
  • 10,921
  • 9
  • 54
  • 93
  • 3
    Note that you should never invent a name that starts with an underscore and either a capital letter or another underscore. Such names are reserved for "the implementation" (meaning the C compiler and the writers of the standard C libraries) to use. By using such names, you are treading on their name space and run the risk of being interfered with. Use a name such as `MYHEADER_H_INCLUDED` (or `MYHEADER_H`) rather than risk messing with the implementation. See [§7.1.3 Reserved Identifiers](http://port70.net/~nsz/c/c11/n1570.html#7.1.3) for more information. – Jonathan Leffler Dec 20 '17 at 22:58