How do you associate .c and .h files with the same name?

Question

When reading the source code of the library, I see that there are .c and .h files with the same name. The main source includes an .h file, but not a .c file. When I look at the code in the .h file, it also does not #include .c file with the same name. Am I missing something? The compiler automatically includes the .c file when the .h file with the same name #include 'd?

Answer 1

Typical .h files serve as the "table of contents" for a .c file, including things like function prototypes, typedefs, etc. Programs include .h so that they know about functions and types.

The .c files are compiled separately and create object files ( .o or .obj ) that contain the actual code.

The object files are then linked to the main program through a Makefile, Project, or similar method. Then the object files are linked to the main program, producing a functional whole.

In the case of libraries, there is no main program. Object files are gathered together and placed in a special format (for static or dynamic libraries). Any program using the library will include .h , as described above, and a link to the library.

Answer 2

There is no magic. When C is compiled, there are two important steps for it.

First, each individual compilation unit is compiled into isolation. (A compiler is basically one .c file, plus everything that it includes).

At this stage, he does not know anything about what is contained in other .c files, which means that he cannot create a complete program. It can generate code with a few spots to fill in the blanks. If from foo.c you call a function declared in bar.h and defined in bar.c, then the compiler can only see that the function exists. It is declared in bar.h, so we must assume that a complete definition exists. But since this definition is inside another compilation module, we cannot yet see it. Thus, the compiler generates code to call the function, with a small note on it saying: "Fill in the address of this function when it is really known."

Once each compilation unit has been compiled in this way, you are left with a bunch of object files (usually .o if they are compiled by GCC and .obj if you use MSVC) containing this kind of "filling in the blanks". "

Now the linker takes all these object files and tries to combine them together, which allows you to fill in the gaps. Now we can find the function that we created for the call, so we can insert its address into the call.

Therefore, nothing special happens if the .c file has the same name as .h. This is just a convention that makes it easier for people to understand what is inside each file.

The compiler doesn't care. It simply takes each .c file, plus everything it includes, and compiles it into an object file. And then the linker combines all these object files together into one executable file.

Answer 3

No. There is no need to include .c files in .h..h files, files are usually not transmitted directly as compiler input, but their sole purpose should be included by other files.

Usually this is something like:

 "ac" includes "ah" "bc" includes "ch" 

You compile "ac" and "bc" and link the output files.

Answer 4

The .h file contains function declarations in the .c file. These declarations are needed by other .c files that want to use the functionality of another .c file. .C files are never included with .h files.

Each of the .c files is compiled into an object file, and all these object files are then combined into libraries or applications.

Answer 5

The preprocessor does nothing magical.

To include something inside the included directory (hard to do with your own headers)

 #include <foo.h> 

or include something in one compilation directory

 #include "foo.h" 

All this makes the text foo.h and connects directly to the output. gcc ac -E will output what it will look after preprocessing.

This is a “dumb” process in that writing your own program that will handle #include correctly is just a trivial exercise.

Answer 6

There is a bit of a wrong opinion in your question. You compile * .h files and, ignoring the built-in lines, you link * .c files.

If you go back to the basics, you can say that:

• ".h" is your interface to the library, that is, what you must compile, and
• The corresponding * .c file is an implementation of what you intend to execute.

So, as an example:

• the add_integers.h file simply declares a function, say addInts (), which takes two integers and returns an integer that is the sum of two, and
• the add_integers.c (pp) file provides an implementation of the addInts () function, which uses an algorithm that takes two integers, combines them, and returns the results.

The developer of the addInts () function can make changes to the software that implements the addInts () function.

Providing the interface to the addInts () function does not change at all (for example, addInts.h does not change at all), then a new shared library containing a modified implementation of the addInts function can be distributed without people having to recompile the new version of the addInts library.

Wow! Why does reading this explanation sound like Danny Kai and “ Arctic Flying Ship ?? ”

Perhaps you should take a look at the work of Bertrand Meyer with Eiffel and Design by Contract .

Answer 7

If I want to create a static library in C or C ++, I will put the prototypes of my functions in .h and the actual function codes in .c or .cpp. After that I compiled my .cpp to make .lib

To associate my .h with my .lib, I write this preprocessor command in .h

 #pragma comment (lib, "theNameOfTheLibFile.lib") 

After that, if I include .h in the program, my program knows where to find the appropriate library.