3

Possible Duplicate:
C++ Header order 

// Here is module This.cpp
#include <boost/regex.hpp>
#include <iostream>
#include <math.h>
#include "mystring_written_by_c.h"
#include "mystring_written_by_cpp.h"
#include <list>
#include <string>
#include <stdio.h>
#include "stdafx.h" // for precomp
#include <tchar.h>
#include "This.h"
#include <Windows.h>
#include <Winsock2.h>

They are ordered by alphabet now.
I'm finding the best practice for ordering them. (Is there a nice formula?)

How will you order these header files? Why?

Community
  • 1
  • 1
Benjamin
  • 10,085
  • 19
  • 80
  • 130
  • Do you have an error, or are you asking what's the best practice for ordering `#include` directives? – Rafe Kettler Jan 26 '11 at 02:47
  • 2
    Possible duplicate: http://stackoverflow.com/questions/614302/c-header-order. Also: http://stackoverflow.com/questions/2762568/c-c-include-file-order-best-practices. – Maxpm Jan 26 '11 at 02:52
  • Also see http://stackoverflow.com/questions/1014632/clean-up-your-include-statements/1014671#1014671 – Fred Nurk Feb 01 '11 at 21:19

4 Answers4

6

Headers should be written to, as much as possible, 1) be independent of what may have already be included, and 2) not introduce problems (such as macros for common identifiers) for headers later included. When both of these are true, the order in which you include doesn't matter. If these aren't true, you should fix that in your own headers, or deal with it as necessary otherwise.

Thus, the choice is arbitrary, but it is still important that you make a choice! "The plan is nothing, but the planning is everything." Consistency leads to more readable code.

A relatively common order is standard library, system (as in OS), external libraries, and then headers for the same project as the current file – with the one exception of an implementation file including its "corresponding" header (if there is one) first, before any includes or other code. Within each group, I sort alphabetically by habit, because, again, it's completely arbitrary but some easy to use order lets me quickly read and update the list.

Applied to your list:

// first only because this is required in your precompiled header setup
#include "stdafx.h"

// it's too bad this can't really be first
// I'm guessing "This" refers to the corresponding header
#include "This.h"

// C stdlib then C++ stdlib is what I usually do,
// whether the C headers are spelled XXX.h or cXXX.
#include <math.h>
#include <stdio.h>
#include <iostream>
#include <list>
#include <string>

// someone mentioned winsock2 needs to be before windows
#include <Winsock2.h>

#include <tchar.h>
#include <Windows.h>

#include <boost/regex.hpp>

#include "mystring_written_by_c.h"
#include "mystring_written_by_cpp.h"

The line breaks above to split into groups are deliberate. I would leave a comment on why winsock2 is given its own group, but the rest of the comments would not normally be there.

Fred Nurk
  • 13,952
  • 4
  • 37
  • 63
  • Nice explanation. Is there a reason, C header should be imported before cpp. Just personal preference? – Benjamin Jan 26 '11 at 03:28
  • @Benjamin: Nothing more than personal preference. – Fred Nurk Jan 26 '11 at 03:28
  • Why should corresponding header be first(actually second if it has precomp) – Benjamin Jan 26 '11 at 03:32
  • @Benjamin: It is an easy way to detect whether that header is missing any includes that it needs, as anything it needs but doesn't itself include would not be present at that point. I have issues with this style of precompiled headers anyway, and would suggest you not use it. However, if you want to use it, you must use it correctly, which means nothing which isn't in the "precompiled-mark header" can come before that header is included. – Fred Nurk Jan 26 '11 at 03:39
  • @Fred: What does *suggest you not use it* mean? Does it mean *Do not use precompiled header?* -I'm a English newbie – Benjamin Jan 26 '11 at 03:44
  • @Benjamin: It means do not use stdafx.h in your list (and turn off that option in your compiler), or make stdafx.h be a blank file. You can switch between these choices, if you find that precompiled headers significantly help your build times – but there's no point using precompiled headers until build times are a problem. – Fred Nurk Jan 26 '11 at 03:53
  • @Fred. Little shocked. I've always used precompiled header for the build time even if it's a small project.(And, you know, it is a default option Visual Studio) Most people don't use precompiled header? – Benjamin Jan 26 '11 at 04:03
  • @Benjamin: I find I *very* rarely need it. I don't know what most people do, but I know I've seen it hide more problems than it seems to solve – especially from beginners, but also for those not constantly vigilant for those type of problems. For example, your mixing of stdafx.h later in the header list in the question should be causing this type of problem, if stdafx.h is used correctly. – Fred Nurk Jan 26 '11 at 04:12
3

It is highly dependent on how you need them included. If none are dependent on another, you are relatively free to include using your own scheme (generally speaking, most important header files will be implicitly included if required by another).

Please note, however, that WinSock2.h must be included before Windows.h or else there is a high possibility that you will get a linker error at compile time.

Good luck!
Dennis M.

RageD
  • 6,693
  • 4
  • 30
  • 37
  • 1
    Or just define `WIN32_LEAN_AND_MEAN` which sidesteps this problem by not including everything in `windows.h`. – Joey Jan 14 '14 at 15:14
2

It doesn't really matter what order you put your header files. This is mostly a matter of choice. Many people put the system headers (the ones between <>) first and the private headers afterwards, but it's up to you.

Simon Jester
  • 303
  • 2
  • 5
  • I don't think so. It's important for header dependency. – Benjamin Jan 26 '11 at 02:47
  • 3
    @Benjamin If header dependency is a big issue, the headers should just use include all their depencencies and have include guards. – Maxpm Jan 26 '11 at 02:57
1

Standard library, then system headers not in the standard library, then private headers. Separate each category by a blank line. Comment anything that needs explanation.

If you have dependencies, include the ones that headers depend on before the headers that depend on them (doi!).

Rafe Kettler
  • 75,757
  • 21
  • 156
  • 151