By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,902 Members | 1,552 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,902 IT Pros & Developers. It's quick & easy.

header files & #includes

P: n/a
Is it best to place all #include files in one header file seperate
from all the other files in a project?

What is the logic that determines the order of the #include files,
does it depend on the order of function calls in main?
Jul 22 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a

"header_question" <he****@file.net> wrote in message news:28********************************@4ax.com...
Is it best to place all #include files in one header file seperate
from all the other files in a project?
If a header file needs something in another header itself, then included it in the
header. Otherwise included things in the cpp files as they are needed. For
example. If your class definition in your own header needs vector, include it
there.
What is the logic that determines the order of the #include files,
does it depend on the order of function calls in main?


No, the only thing that matters is that things that declare things used in
later includes have to be included first. Again this is accomplished
easiest by including things as they are needed.
Jul 22 '05 #2

P: n/a
"header_question" <he****@file.net> wrote in message
news:28********************************@4ax.com...
Is it best to place all #include files in one header file seperate
from all the other files in a project?
It's not something I would do.

What is the logic that determines the order of the #include files,
does it depend on the order of function calls in main?


It does not depend on the order of function calls. If header file A includes
(or might include at some future date) header file B, then I think B should
go first. I usually put standard headers first, third party headers next,
and my own headers last. (Standard headers never depend on third party
headers, and third party headers never depend on my own headers.)

--
Cy
http://home.rochester.rr.com/cyhome/
Jul 22 '05 #3

P: n/a
header_question wrote:
Is it best to place all #include files in one header file seperate
from all the other files in a project?

What is the logic that determines the order of the #include files,
In most environments, the headers can be included in any order, and
there is no advantage to including them all in one "master header."

In environments that support pre-compiled headers, there is often a
significant advantage to including headers in the same order within each
translation unit. In this case, the "master header" approach can be
useful. Unless you know that you are using such an environment, don't
bother complicating your file structure.
does it depend on the order of function calls in main?


No.

Jul 22 '05 #4

P: n/a
On Thu, 01 Jan 2004 20:11:42 +0000, header_question wrote:
Is it best to place all #include files in one header file seperate
from all the other files in a project?
Normally it is frowned upon. Include only what you need. The only
exception is when you use precompiled headers, in that case the
compile-speed can increase dramatically from placing all includes in a
single file. In practice I find this does not really work, as I more often
change include files than source files (thanks to templates), negating the
gain.
What is the logic that determines the order of the #include files,
does it depend on the order of function calls in main?


There should be no hard dependencies between include files, so
technically, include them in any order you want.

My eprsonal standard is
- First project include files
- Then own library include files
- Then 3rd party include files
- Last standard library include files

The reason is that this makes it easier to spot when an include file does
not include a required include file itself. Others disagree with this
though, it is mainly a style issue.

HTH,
M4

Jul 22 '05 #5

P: n/a
My personal preference is the reverse:
My eprsonal standard is
- First project include files
- Then own library include files
- Then 3rd party include files
- Last standard library include files


1.) standard library include files
2.) 3rd party include files
3.) my own include files
4.) the project include files

--The Directive
Jul 22 '05 #6

P: n/a
On Thu, 01 Jan 2004 18:44:56 -0800, The Directive wrote:
My personal preference is the reverse:
My eprsonal standard is
- First project include files
- Then own library include files
- Then 3rd party include files
- Last standard library include files


1.) standard library include files
2.) 3rd party include files
3.) my own include files
4.) the project include files


Any reason for that?

M4

Jul 22 '05 #7

P: n/a

"The Directive" <th***********@hotmail.com> wrote in message
news:84**************************@posting.google.c om...
My personal preference is the reverse:
My eprsonal standard is
- First project include files
- Then own library include files
- Then 3rd party include files
- Last standard library include files


1.) standard library include files
2.) 3rd party include files
3.) my own include files
4.) the project include files

--The Directive


Thanks to Lakos "Large Scale C++" for pointing out to me that regardless of
the order of the rest every .cpp should always
include its own .h file first.
The reason: If you do this then every compile checks that the .h file stands
on its own as it should (i.e. does not require other headers and or using
directives to be included before it).

eg. the most common problem is that you get X.cpp defining ostream&
operator<<(ostream&,X&) and not including
<iostream> or <iosfwd> or not fully qualifying the names such that it will
only compile if all headers use:
#include <iostream.h> // i.e. <iostream> using std::iostream;
#include "X.h"

If this strategy is followed consistently then it gaurantees (at least where
there is a cpp for each .h) that the order of the rest does not matter.
This is so useful that I have a policy of creating a trivial cpp file for
every .h even though all it contains is a #include of the header.

Having started with "X.h" aesthetics would tend to favour the order

FIRST "X.h"
- First project include files
- Then own library include files
- Then 3rd party include files
- Last standard library include files

Jul 22 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.