When does a .c file have no associated .h file?

Question

In most cases, in C programming, it seems that there will be one header file ( .h ) for the function prototypes for the code file ( .c ).

When would it be appropriate not to have a header file for a code file?

Answer 1

There are several use cases for this. The most obvious is that your main program rarely needs a header file.

Secondly, you do not have one header for each file C. I have compiled libraries before (let’s say BTree libraries for the purpose of this answer), where each separate function is in its own source file, but there is a library header file, something like :

 btree.h btree_priv.h btreeInit.c btreeDestroy.c btreeConfig.c 

etc. A private header file is intended for materials that should be shared between the code, but should not be published in the API.

Answer 2

most obvious when .c completely autonomous and does not need prototypes or extern for other .c files. this is mainly only for very small programs or programs that are exported via the def file for the plugin to a predefined interface.

Answer 3

I saw massive code bases where one .h file defines the interface for some component, and several .c files implement it. The implementation was divided into several files solely for reasons of convenience and an attempt was made with some logical boundaries.

It can be argued that such a logical boundary can be used to separate the component into subcomponents and, therefore, has several header files, but design decisions are rarely a black and white thing, and sometimes this approach makes sense.

Answer 4

When the .c file contains data that should not be used by any code.

Admittedly, this is rare, but it can happen. For example, I did this on embedded devices to fill the clipboard buffer with loading graphics.

Answer 5

If you split your program into several modules, there will usually be a “main” module that contains the main () function, and possibly some other things. If this module does not have anything that should be called or used by another module, you do not need to export the interface to a .h file.

Answer 6

I think that expecting a 1 to 1 mapping between .c and .h files is a poor initial assumption. Drop it and start fresh .: D

If you look at your question differently, you may ask, "When is it appropriate to create a header file?"

I suggest the following, where the term "code module" is a group (usually a directory) of one or more related .c files:

• Create a header for public interfaces / definitions that should be available for other code modules.
• Create a header for private interfaces / definitions that should be shared in a code module but not shared with other code modules.

These are the header files you need. If none of them are required, you do not need a heading.

Some coders like to artificially separate prototypes / macros / typedefs / etc in .h separately from global / functions in their .c. I recommend against this approach and suggest having all the related functions in one file. Then go to the headers as necessary things that are absolutely necessary to prevent "extern in other .c files".

Answer 7

In case you do not need the declarations from the .h file, but it really is never.

Answer 8

Often I create a header file for "main", even if I do not expect other code to have access to it, since often either (1) building the debugging ultimately requires something outside the main module, to access something either in it, or (2) the main module ultimately needs to be split due to compiler (embedded system) limitations. The presence template for each .c file includes its own .h file, strong enough that I often create almost-empty .h files even for .c files that define things that are not referenced in the code (for example, interrupt interception tables and etc.).

Naming conventions become a little more complicated when a file contains several files generated by the program, or includes files that need to be compiled more than once (for example, one of my projects has two engines whose code is identical, except that they use different I / O and various variables, my motor.c file contains:

  #define LOCK L0
 #include "motor.i"
 #undef LOCK
 #define LOCK L1
 #include "motor.i"
 #under lock

Note that on this built-in compiler, the → operator is very inefficient, so an operator like:

  L0.speed ++;

will compile with one instruction, and an instruction like:

  L0-> speed ++;

will be transferred to five teams if “speed” is the first element in the structure, or seven if it takes any other position. Thus, a much more efficient speed and slightly more efficient area to duplicate a code with constant resolvable addresses than having one manual processing of both engines.

If there is an additional file associated with the .c file and it contains real code, I will call it ".i". Not sure what to do if there is more than one.