What Evil Lurks in a Header File . . . ?

As a beginner, your first exposure to a header file is most likely <stdio.h>, which you understand is necessary for some reason. Then you may confuse the header file with the library, which is common but wrong. And you may even dabble with your own header files. Beyond that, few tutorials bother to mention any necessary details about what should go into a header file and when it’s necessary . . . until now.

The header file is tied to the preprocessor directive #include. It’s function is to insert another file inside your source code file. You can include any file, even another source code file, if you like. Traditionally, header files are included:

#include <stdio.h>

The angle brackets, < and >, direct the compiler to look for the header file in the standard locations, such as /usr/include and /usr/local/include on Unix systems and god-knows-where in Windows. When double quotes are used, the compiler looks in the current directory or the specified pathname:

#include "myheader.h"

The compiler may also have flags directing it to look in a specific location:

-I~/include/curl/

Above, the /include/curl/ directory in the user’s home folder is scanned for header files. And the CFLAGS environment variable can be set to specify compiling options, which includes the “include” directory.

As far as contents go, you can put anything in a header file that normally goes into a source code file. No rules exist, though it’s customary for a header file to include the following:

  • Other header files
  • Function prototypes
  • Constants
  • Typedefs
  • Structure definitions
  • Macros

Header files come into play for standard library functions, as they provide the function prototypes, structures, macros, typedefs, and other items that you must otherwise write in your source code. Beyond that, the only time I use a header file is for a multi-module program.

For example, when I’m coding some complex utility or game, I put all the function prototypes, structure definitions, and constants within the header file. I also place into that header file any other header files required by the code, such as stdio.h, stdlib.h, and so on. This collection allows the source code files to remain rather brief. Each one might just have the following, sole preprocessor directive:

#include "myheader.h"

You can also put C code into a header file, which is more popular in the C++ language than in C. No rule restricts you from placing code into a header file, it’s just not that common. I would offer that doing so obfuscates your main source code file because the functions held in the header file aren’t obvious to anyone else. I even go so far as not to include macros in my own header files, as I want to see all the gears and levers in one spot, which helps for debugging.

As an aside, when I reach the point in a multi-module program when I need a custom header file is usually the point when I give up on command line programming and use an IDE or editor. It’s just easier to manage such programming complexities in that environment as opposed to being the purist that I am and coding at the command prompt.

4 thoughts on “What Evil Lurks in a Header File . . . ?

  1. A header file provides a handy reference or source of documentation for the code which uses it. If you are using code consisting of a .h and a .c then the short .h file usually tells you everything you need to know without looking through the much larger .c file.

    In the mid 90s I taught myself raw Windows API programming (well, tried to) from an excellent book by Charlie Calvert. I remember that in the intro he said that the book was basically a commentary on the windows.h file which I thought was quite profound and insightful.

  2. Thanks for the insight, Chris. I also agree that placing documentation into the .h file is yet another use for that resource.

  3. I wasn’t really suggesting putting documentation in the header, just that the function prototypes, typedefs etc provide their own concise documentation. Perhaps a comment for each one would also help but I feel a separate file should be used for full documentation.

    By the way, have you considered putting the source code from your blog posts on Github?

  4. Re: Github. I’ve made moves in that direction a while back, so I must lookup my account info. I might even make that today’s project!

Leave a Reply