Tag Info

Hot answers tagged

43

You should always include all headers defining any objects used in a .cpp file in that file regardless of what you know about what's in those files. You should have include guards in all header files to make sure that including headers multiple times does not matter. The reasons: This makes it clear to developers who read the source exactly what the ...


15

The general rule of thumb is: include what you use. If you use an object directly, then include its header file directly. If you use an object A that uses B but do not use B yourself, only include A.h. Also while we are on the topic, you should only include other header files in your header file if you actually need it in the header. If you only need it in ...


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 ...


8

I keep wondering whether or not I should explicitly include all headers used directly in a particular file Yes. You never know when those other headers might change. It makes all the sense in the world to include, in each translation unit, the headers you know that translation unit needs. We have header guards to ensure that double-inclusion is not ...


8

While you can include .cpp files as you mentioned, this is a bad idea. As you mentioned, declarations belong in header files. These cause no problems when included in multiple compilation units because they do not include implementations. Including a the definition of a function or class member multiple times will normally cause a problem (but not always) ...


6

Read more on the role of the C and C++ preprocessor, which is conceptually the first "phase" of the C or C++ compiler (historically it was a separate program /lib/cpp; now, for performance reasons it is integrated inside the compiler proper cc1 or cc1plus). Read in particular the documentation of the GNU cpp preprocessor. So in practice the compiler ...


6

To avoid ambiguity, you should always add the trailing slash. Not all files have extensions, so if you use this consistently in your codebase, you (and others) will be able to tell whether a path references a directory or a file at a glance.


5

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 ...


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 ...


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 - ...


2

Should I enforce this coding style? Probably not. My rule is this: header file inclusion cannot be order dependent. You can verify this quite easily with the simple rule that the first file included by x.c is x.h.


2

Opinions differ on this, but I am of the view that every file (whether c/cpp source file, or h/hpp header file) should be able to be compiled or analysed on its own. As such, all files should #include any and all header files that they need - you should not assume that one header file has already been included previously. It is a real pain if you need to ...


1

I am taking a similar slightly different approach from proposed answers. In headers, always include just a bare minimum, just what is needed to make the compilation pass. Use forward declaration wherever possible. In the source files, it is not that important how much you include. My preferences are still to include minimum to make it pass. For small ...


1

Due to C++'s multiple-unit build model, you need a way to have code that appears in your program only once (definitions), and you need a way to have code that appears in each translation unit of your program (declarations). From this is born the C++ header idiom. It's convention for a reason. You can dump your entire program into a single translation unit, ...


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