Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would always typically include dependencies in my header files so that when adding that header to a source file, I don't need to dig around for the other required headers to make it compile.
However, after reviewing some other coding standards, it appears that this is often banned, with the requirement that a header file will not contain any #include statements.
I can't really find any discussion on this - so what would be the reason for banning such a practice, or is it purely down to preference?
--
E.g.
typedef.h contains a typedef for U8.
my_header.h declares void display_message(U8 arg);
Should the reference to typedef.h go into my_source_file.c or into my_header.h ??
I see no good reason for not allowing headers to include their prerequisites.
Consider deleting an #include from a source file. For example, suppose the code has been modified to no longer use foo.h, so the #include for that is being deleted. But the source files has a dozen #include statements. Which other ones should you delete because they are no longer needed? Hopefully, foo.h documents its prerequisites, so you can identify those candidates for deletion. However, if you delete their #include statements, you might be deleting a prerequisite that is needed by a different header file. So you must check the prerequisites of every header file.
In contrast, if headers include their prerequisites, then you can simply delete #include <foo.h> and be done with it.
Includes should go in the source file. The header should only declare functions and variables of your source code file (that is typically the standard).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 days ago.
This post was edited and submitted for review 7 days ago.
Improve this question
I have to write some Windows code, and I want to separate it from the Linux part as much as possible.
At one point I need to check for NULL in the Windows code, but I don't want to include stdio.h or stdlib.h.
I strongly suspect that NULL is defined somewhere in windows.h, but I can't find the page. I found this, which is interesting, but doesn't tell me what I want to know.
NULL is defined in the standard C header stddef.h, period.
If you run for example gcc/mingw port in Windows, you can just tell any half-decent IDE to find the declaration of NULL and end up in stddef.h where it says #define NULL ((void *)0).
You can also create a source file like this:
// main.c
#include <windows.h>
int main (void)
{}
Then compile with gcc main.c -H. This will expand all header dependencies, so you'll see which header that includes what other headers. You'll get a whole flood of them and you'll notice that stddef.h is indirectly included at some 2-3 different locations.
Conclusion: NULL is not defined by windows.h or any other windows-specific header that you should be including directly.
If you need to use NULL, then the correct approach is to #include <stddef.h> regardless of OS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have a module in my project mymodule.c that provides a lot of functions for the rest of my project.
These function are defined in a mymodule.h header file.
But in mymodule.c there are a lot of other defines or define masks.
For example:
#define STACKSIZE 1024
#define TIMER1 100
#define TCR_MASK 16U
#define TCR 16U
#define TCR_IR (0ULL << 8)
...
100 other defines or typedefs
I could split it up like this:
mymodule.h --->all external functions and declarations used from other places.
Rename this to mymodule_public.h ?
mymodule_config.h ---> configuration like timers, controlparameters or constants.
mymodule_masks.h ---> decsriptors.
There could be more headers.
Another way is to keep all except the external functions in the mymodule.c.
What is best practice for splitting up into headers and giving header names?
Generally, a header file which is the public interface of a library should contain all the things that the caller needs to use the functions.
If you have a bunch of #define that are necessary to use the functions, they need to be in the h file. If they aren't needed but just used internally, you should keep them in the c file.
It is ok to make a 2nd header file which isn't the public API but just contains internal constants used by your c file(s).
As for where to place the #includes, that's a bit subjective. Generally I like to show the user of the library which dependencies the library comes with, so that they can ensure that they have all the necessary files and so that they can trouble-shoot strange linker errors easier. On the other hand, one might feel uneasy about "exposing" includes that are just used privately by the library in the public header (like the 2nd private header mentioned above). There's no obvious right or wrong here, though try to be consistent with where you place the #includes.
Your idea with multiple headers all named with a certain library-specific prefix "mymodule" is pretty sound overall.
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.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
In my main function I call the functions declared in my header file. I have imported my header file in the main. However, the compiler gives a undefined reference to function. The implementation of the functions of the header file are in another C file. To compile and work my main, I have to import the C file.
My question is: Why do I have to import the C file in addition to the header file.
For example when I include stdlib.h does this file also have the implementations of its functions or just the declarations?
If your code does not work unless you #include a C file, you are not compiling it right. You should compile the two modules separately, with the main module including only the header for your other module. Then you should link these together.
On UNIX running gcc you can do compilation and linking with a single command:
gcc helper.c main.c
Note: If you are developing on UNIX, you should learn how to use makefiles to manage separate compilation. Here is a tutorial covering the use of makefiles for compiling C++ code.
You don't have to include header files (sometimes), but linking with object files is mandatory. Object file contains the body of functions you try to use and that's why they can't be called without it.
Read further to find out why headers are important and their history
'#include" just tells the compiler the interface of the file that you are using. (The declaration). #include will make your compiler happy.
In addition you have to have the actual implementation(the definition) which is typically in the *c file. This makes the linker happy.
If you include the stdlib.h - the right C runtime is included for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm looking for a "best practice" to document my C code. Like in any project I have some header files ".h" and the respective source file ".c"
In the header file what kind of comment you put in? And in source files?
The question arise up because since I commented well my header files, the c files looks like a mess.
What's your best practices in keeping the code well commented?
The header is meant for users of the code. So in there I document the interface: how to use it, preconditions and postconditions, etcetera.
The .c file is for maintainers. In there, I document the implementation: how things work internally, and why they work that way.
I suggest adopting the conventions imposed by a tool like Doxygen. Then instead of just code comments, you can also generate HTML/PDF/Latex etc documentation and its gives you good conventions.
Agree with Thomas about the cpp files
If this is a personal project I'd suggest there are plenty of coding standards out there you could adopt (almost all include sections on how to lay out comments).
If not, I would imagine your company / teaam / project already has something in place so use that.
For source files I suggest you create a comment template for File Header and Function Header.
In case of File Header Comments, you should have a brief description of the file, function names, author, date of creation and history to record modifications.
Incase of function header, you can explain the logic and purpose of the function and various parameters. Please ensure that any complex logic or deviation from common behaviour is well documented through comments.