This question already has answers here:
Header per source file
(7 answers)
Closed 8 years ago.
On most tutorial I could find on the web I have notice that everyone is creating header files for everything and never include a .c file.
I couldn't find any good explanation on the web about why you need the header file.
I have read that including the header file allows you to not repeat yourself which doesn't make sense to me. The header file IS a repetition of all the declaration of your implementation, if you include your implementation directly, then you avoid this overhead right!?!
Don't get me wrong, I can understand the use of header file when you are doing libraries : Several project can include only the header file and then linking to the same library (e.g. the standard library) thus ending up with a smaller executable. I just don't see the benefit of header file when you include something which is completly specific to your project...
Can you explain me the real benefit of header files?
Suppose you have a program built from 10 source files. If each one included all the code that was needed (including, presumably, the implementations of the standard C library functions it uses), you'd have lots and lots of multiple definition errors when you link all the bits together.
So, a header (normally) includes just the declarations. The object code for the corresponding source code is linked with the program, either as explicit object files or as libraries. This stops you getting multiple definition errors.
Related
Why should I use another source code file to share code or a function between many programs and use the linker instead of using a header file only? (I read this in Head First C but I didn't understand what is the point of it)
Generally, header files should only be used to declare your functions/structs/classes.
The actual implementation should be created in a separate .c file which then can be built and exported as a binary along with the header.
Keeping the implementation in the header has many drawbacks.
Bigger footprint - the header size will be bigger since you have
more symbols in it.
You cannot hide the implementation from the end-user.
The compile-time will be a lot larger since all code has to be processed every time it is included by the compiler.
Just to name a few. They might be many more reasons.
However, there are some cases when it is okay/better to include some logic in the header files.
For example for inline functions which may improve the runtime of the application while maintaining good code quality and/or templates in C++.
Generally, header files contain declarations, like function signatures, while the function definitions (the actual source code) are located in separate source files.
Multiple files can include the same header file and share function declarations at compile time. But they also must share the source files (the files must be linked together) in order to have access to the function code at run time.
This question already has answers here:
What is the point of header files in C? [duplicate]
(4 answers)
Closed 3 years ago.
When I program in c there are .h files .
Header files contain the signatures of functions that are implement in c files.
Why are header files are needed as I can include the c file to use the function there instead of using headers.
Is this to make the compiler's job easier?
TLDR answer is organization and code reuse.
Header files contain common standard code usable across multiple code bases - think of them as libraries to bring in.
This code is kept separate for maintenance issues. You only want one copy, so when a fix needs making it happens in one place. All of the various code bases you have that reference that one included header file suddenly have the updates.
You can also do project specific headers. For example, my SQL statements are all static strings, since they are long and complex I keep them in a different file and just include it. This way, I don't have a large long blob of complex SQL as a string in the middle of my code.
This question already has answers here:
Should I use #include in headers?
(9 answers)
Closed 6 years ago.
I am reading through an embedded C standard book and I noticed the following:
No header file shall contain an #include statement
What should I do with function declarations that have non-standard types?
example: void function(some_funky_type x);
Throw that book away; it is absolute garbage. In fact, you should burn it, to make sure no other poor soul ever picks it up.
Header files should absolutely include all of the header files necessary for them to be self-sufficient. There is nothing worse than trying to carefully massage the order of your #include statements to be sure that the types needed by one are already defined before it is included.
This is a stupid and counterproductive rule for precisely the reason you identified. The alternative is for every .c file to include all of the .h files that a subsequently included header will require. You can imagine that if you introduce a new dependency in a commonly included header that you will now have to update every C file that includes that header.
This question already has answers here:
Where to document functions in C or C++? [closed]
(10 answers)
Closed 8 years ago.
Suppose we have function (external only considered here) int foo(int a, char *b), normally there will be a header that goes with it documenting what the function does, what each parameter and return value does, etc. It'll probably be in doxygen format too. My habit is that such header should go into .h files because that's where the interface is defined and reader should have all the information in that place. But a lot of people keep such headers in C file where the actual implimentation goes. I've seen this in the Linux kernel code also. So was I wrong? Which would you prefer?
Although header files can be used in any which way, they are primarily a mechanism to enable external linkage.
You design an API that is meant for external consumption, and you put everything required to consume this API (constants, types, prototypes) in header file(s).
All the other stuff, that is a part of implementation, and doesn't need to be seen by external users, can go in the source files (if the usage is localized to one file), or private headers that can be shared between multiple files. The latter is another example of header files enabling external linkage, but for internal consumption.
The answer to this question is largely "it depends":
Depends on what? Who's reading the documentation, and how they access it.
If you're developing a program, then having the documentation inline with the implementation is probably OK, because anybody who wants to know about your program can access the source code and read about it. Your target audience is probably developers working on the program itself, so having the documentation in the C file, along with the bulk of the code they're working on, is a suitable approach.
If you're developing a library, the target audience changes (or you might have two target audiences). You still have the developers, who could make use of more detailed documentation as it relates to private implementation detail. You also have the users of the library, who only care about the interface that they're working with; from a code-browsing point of view, they typically only have access to the headers.
I put them in the .h file by preference when it's my choice, if I have a .h file. If I just have a .c file, I will document the functions when they are defined, simply because if I just have a .c file, I'm probably still coding, and I want to change the documentation if I change the code.
I feel that documentation and declarations go together in a separate file in a finished c project. Documentation in the code breaks up the code and can be redundant.
If I'm contributing somewhere, I'll follow the established convention.
This question already has answers here:
What is the point of header files in C? [duplicate]
(4 answers)
Closed 9 years ago.
Is there a need to create a header file after making a source file? What are the things included in a header file? is it necessary or is it good for only source files containing a function definition?
I'm really confused since what you put in header files, such as function portotypes, can also be placed in a source file. Are header files only good for declaring global variables? Is creating a header file with the same name as your source file necessary.
I already got the answer of "What are header files for". Apparently a lot of questions similar to this have been posted that's why adding some follow up questions.
I guess you could search on Google and find whatever your need to know but to make it short:
In C (and C++), every source (.c or .cpp) file is compiled on its own translation unit. This means that every file is compiled on its own to produce an object file. Once all object files are compiled, they are linked together to create your final binary file.
This means that a source file has no clue of what's defined in other source files, the header file is needed to fill this gap: it provides the declarations of variables, functions and whatever that are implemented in one or many source files, so that, when you are including it inside another source file, the compiler can verify that all these external things are correctly used. This is not its only purpose, it can aid in other taks (like reuse of code or partitioning) but this is why it exists.
The header file is literally included when you use the #include directive.