Custom headers above standard?

Question

Is it possible to place custom headers higher in the include section than standard headers? For example, include a section in someclass.hpp :

 #include "someclass.h" #include "global.h" #include <iostream> #include <string> 

Is this the best practice? What is the profit, if any?

Answer 1

The reason is that if you forget to include the dependent header in someclass.h , then any implementation file will include it as the first header, it will receive a warning / error undefined or undeclared type and something else. If you include other headers first, then you can mask this fact - assuming that the headers included determine the required types, functions, etc. Example:

my_type.h:

 // Supressed include guards, etc typedef float my_type; 

someclass.h:

 // Supressed include guards, etc class SomeClass { public: my_type value; }; 

someclass.cpp:

 #include "my_type.h" // Contains definition for my_type. #include "someclass.h" // Will compile because my_type is defined. ... 

This will be compiled. But imagine that you want to use SomeClass in your program. If you did not my_type.h before including someclass.h , you will get the compiler error my_type undefined. Example:

 #include "someclass.h" int main() { SomeClass obj; obj.value = 1.0; } 

Answer 2

This is common practice for #include "widget.h" as the first thing in widget.cpp . This means that widget.h is autonomous, i.e. It is no coincidence that it depends on other header files.

In addition, I think that this is, in fact, a matter of personal preference.

Answer 3

There are two important points that you need to make before delving into the specifics:

• When developing a new header / source pair, it is important to verify that the header is self-contained. To do this, the easiest way is to include the first in the file.
• It’s better not to include extraneous things before including a header that you don’t have, as this can create strange problems in the event of a macro conflict or function overload.

Therefore, the answer depends on whether you have a unit test or not.

A general rule is to include headers starting with the standard library, and then third-party headers (including open source projects), and then your own middleware, utilities, etc ... and finally headers local to this libraries. This more or less corresponds to the order of dependencies for observing observation 2.

The only exception that I saw is a single header corresponding to the current source file, which will be included first to make sure it is self-contained (observation 1) ... but this is only true if you do not have unit tests, because if you do this, the unit test source file is a very good place to check this out.

Answer 4

Start with the system headers.

If there is no dependency between the headers between the two headers, but since programming is essentially related to communication, not to the computer, but to other people, it is important to make it logical and understandable. And I think it's better to start with the system headers.

I base this one of my very first programming courses (in 1984, I think), where we programmed in Lisp and taught to think this way: you start with the usual Lisp language, and then create a new language that is more useful for your application, adding some functions and data types. If you, for example, add dates and the ability to manipulate dates, this new language can be called Lisp -with-date. You can then use Lisp -with-dates to create a new language with calendar functions, which could be called Lisp -with-calendars. Like layers in a bow.

Similarly, you can see that C has a “main” language without any headings, and then you can, for example, extend that language to a new, larger language with I / O functions using #including stdio.h. You add more and more material to your main language with #, including more headings. (I know that the term “C language” in other contexts refers to the entire standard with all the standard headers, but they carry me here.) Each new #include header creates a new, larger language and an additional onion layer.

Now it seems to me that the standard headers should obviously be the inside of this bow and, therefore, before the custom headers. You can create C-with-monsters by adding material to C-with-I / O, but the people who created C-with-I / O did not start with C-with-monsters.

Answer 5

Although this is just a personal choice, I would prefer to include standard headers first. A few reasons:

• Any set of #ifdef..#define will display correctly, not the standard headers that misinterpret them. This applies to conditional compilation, as well as the values ​​of some macros, while standard headers are compiled.
• Any variable / new function in the standard header may conflict with your function, and the compiler will emit an error in the header file, which would be difficult to solve.
• All required standard headers should be placed in one heading (preferably some precompiled heading), including this heading, and then include your own heading. This will reduce compilation time.

Answer 6

any place you turn on the C ++ compiler treats it as the same