Tag Info

Hot answers tagged

12

It depends on what code is in the include file. Did you try putting the #include for <stdio.h> inside main()? Depending on how the standard library is implemented on your system it may not even compile. Header files can contain not only function declarations, but function definitions. Standard C doesn't support nested functions. If your header file ...


11

C programmers, on the whole, will expect the #include directives to be at the beginning of the file. Why risk confusing them without any significant benefit?


10

If a header file such as file.h depends on other headers such as stdio.h, then file.h should #include those headers as necessary. Each header file should keep track of its own dependencies, and use #include guards to prevent multiple translation if it winds up being included several times: #ifndef FILE_H #define FILE_H #include <stdio.h> ... void ...


5

Consider the possible things that may be found in a header file. Preprocessor macros. These will be available from the #include until the end of the .c file that includes the header. Preprocessor macros are not concerned about C block scope (braces), so even though the header is inside a function, the macros will still be available after the end of the ...


4

This is one of those "should" rather than "shall" kinds of coding standards. The reason is that you would pretty much have to write a C++ parser to enforce it. A very common rule for header files is that they must stand by themselves. A header file must not require that some other header files be #included before including the header in question. This is a ...


3

Its really very very bad! The reason is that many C header files include lot of macro stuff like:-- #if !defined(MYSTUFF_INCLUDED) /* File not yet included? */ #define MYSTUFF_INCLUDED /* Show file now included */ int variable1; int variable2; #endif macro variables have a "file" scope whereas any variables defined ...


2

If you need to enforce a rule that particular header files must stand on their own you can use the tools you already have. Create a basic makefile that compiles each header file individually but doesn't generate an object file. You will be able to specify which mode to compile the header file in (C or C++ mode) and verify that it can stand on it's own. You ...


2

I would refrain from changing vendors the headers, and work around limitations unless the workaround is being used too many times (more than once?). I now apply the following a guides. In most cases its presumptuous to think I know better than the vendor. (he says with only a slight hint of sarcasm) Upgrading the tool chain later can be a problem - ...


1

doesn't #Pragma once achieve this? You can include something as many times as you want, either directly or via chained includes, and as long as there is a #Pragma once next to each of them, the header is only included once. As to enforcing it, well maybe you could create a build system that just includes each header by itself with some dummy main function, ...


1

I don't think such a tool exists, but I would be happy if some other answer disproves me. The problem with writing such a tool is that it very easily reports a false result, so I estimate the net advantage of such a tool to be close to zero. The only way such a tool could work is if it could reset its symbol table to just the contents of the header file it ...



Only top voted, non community-wiki answers of a minimum length are eligible