Large project development: header file Order

Experience has taught us that some coding practices, while fully legal in C + +, must never be applied to large project environments. A large project environment must have appropriate constraints, otherwise it can easily become difficult to control and difficult to maintain (excerpt from << large-scale C + + programming >>). The following is an example of the header file order defined in the two coding style used in chromium.

Differences in header file order

Webkit/blink follows the definition of industry standards and is in fact Lakos in the order recommended in << large-scale C + + programming >>:

1. The header file corresponding to the compilation unit (related header files).
2. Other header files within the project.
3. Library and system header files.

(Blink special Point is that the compilation unit must first contain the config.h. )

The purpose of this is to avoid implicit reliance. Each header file should be self-contained (self-contained, or sufficient), which ensures that the user can understand its physical dependencies directly in the header file. If this order is followed, it cannot be compiled when there is an implicit dependency.

The following example:
My_class.h relies on std::string, but there is no explicit inclusion, and when main contains the header file string for the standard library, the compilation is not error-free.

main.cc

#include <string> #include <iostream> #include "my_class.h" int main (int argc, char* argv[]) {  MyClass ainstance;  Std::cout << ainstance.value () << Std::endl;}

My_class.h

#ifndef My_class_h_#define my_class_h_class MyClass {public:  MyClass ();  Const std::string& value (); Private:  std::string value_;}; #endif

If you follow the rules above, you will compile the main.cc times wrong:

In file included from Main.cc:1:./my_class.h:6:9:error:use of undeclared identifier ' STD '  const std::string& val UE ();

In a more clear-level project, mistakes are best attributed to the author. Here main.cc as a my_class.h user, such errors are best solved by the author of My_class.h. So Google defines the following rules:
?The associated header file
?C Library header File
?C + + Library header file
?Other library header files? * Other header files in the project.
You will receive an error when you implement the following my_class.cc:? my_class.cc

#include "my_class.h" #include <string>myclass::myclass ()  : Value_ ("hello!") {}

In this case, this error will only be reported to the my_class.h corresponding compilation unit my_class.cc.

In file included from My_class.cc:1:./my_class.h:6:9:error:use of undeclared identifier ' STD '  const STD::STRING& ; Value ();

If it is a small project, you may not notice the difference. But under a large project with a clear mandate and a collaborative division of labor, it becomes valuable.
This is a small point that can be seen in some of the rules in large projects that define the tip of the iceberg. Again, for example, the header files in large projects have some design tradeoffs. Avoiding unnecessary inclusion of header files, for example, slows down the construction of a project and introduces a predecessor declaration. However, it can cause ambiguity in some scenarios (such as a class in a pre-declared standard library, or a template class), or introduce some maintenance costs and risks (such as a change in the parameters of a function, which requires a corresponding modification of the predecessor declaration). Google's early days were to encourage the use of pre-claims, and it is now only to emphasize that it is recommended to use a forward statement only if it is clearly beneficial.

Extended reading:

Self-sufficient header files in C + +
Headers and Includes:why and how
C + + include file order/best practices

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Large project development: header file Order