仅使用头文件进行编程？

Question

If a header file is just a piece of code that gets pasted onto another when I use #include then what is stopping me from programming in C using only .h files? You can even #include into other header files!

I assume there must be some performance or workflow reason why this isn't more common, but if it exists I do not know what it is.

Therefore my question is: What is the reason people don't program entire applications with just header files?

Answer 1

Header files come with the concept of modularisation, ie of separating the source code of a large program into several independent parts, ie translation units. Thereby, implementation details are hidden to other translation units, and dependencies are dramatically reduced. But: if a translation unit A needs to call a function from another translation B, it needs to have the function prototype of the respective function, ie the function without the body - something like int functionFromB(int x); in order to tell the compiler how to call it. So translation unit A could simple write this prototype at the beginning; but usually functions from translation unit B (eg B.cpp) are exposed in a header file Bh , which comprises all the "public" functions of B in form of function prototypes. Same applies to type definitions and (global) variables. Then A simply can include Bh in order to have all the function prototypes et al. available without the necessity of knowing all the implementation details (like the function bodies).

So you can write a large program completely in .h -files; yet you have to tell the compiler to treat them as translation units (usually only .cpp -files are treated as such), and you still have to provide function prototypes et al...

With translation units, you have separate / independent modules. This is in contrast to a large monolithic block, which you get when you "paste" all the chunks of your program spread over different .h -files by #include -ing them "together". You can compile / test / distribute translation units separately, whereas a monolithic block cannot be compiled / tested / distributed partly.

Answer 2

Header files are a necessity of C and C++ when you need to reference code or data structures across different files, something especially important when external programs that need to link against a library and the compiler has to understand how to use it.

It's advantageous to break up your application into a series of .c or .cpp files in order to make the compilation process more efficient. Most compiler environments, where they're Makefile driven or IDE managed, have methods for detecting which files need to be recompiled when a change is made.

In larger applications building all files can take considerable time, but recompiling a single .cpp file is often fairly quick. So long as you change only the .cpp source and don't touch the headers you can do a quick recompile and relink, ready for testing right away.

If instead you put everything into a header file then you'd need to recompile everything, every time, which can be a painfully slow process.

Keep in mind some code bases can take hours to rebuild, so this is not a sustainable practice.

Answer 3

I thought of a strange analogy.

You go to a restaurant.
The waiter presents you with a menu. The menu is your interface to the kitchen.
You pick the dish(es) you want to order.

Then,

Option 1:

The waiter asks you to move to the kitchen and see for yourself how the dishes are prepared. You remain in the kitchen until the food is served to you.

Option 2:

The waiter brings the food to your table after it is prepared in a kitchen that you don't necessarily see.

Which one would you prefer?

Putting the implementation in the .h file is analogous to Option 1.

Putting the implementation in a .c/.cpp file somewhere else is analogous to Option 2.

Answer 4

Header files are different from source files by convention. Using the .h or .hpp extension communicates that the file is intended to be #included and is not meant to exist as a standalone source file. You can generally assume that .h / .hpp files are safe to include from multiple source files.

Meanwhile, .c and .cpp extensions communicate that the file likely is intended to be a translation unit and is not suitable to be #included in other translation units.

You could very well write an entire codebase with every file having any arbitrary extension, or none at all, if you really want to make it hard on yourself and anybody else working in the codebase.