header files & #includes

[header_question]

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?

[Ron Natalie]

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

[Cy Edmunds]

"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/

[Jeff Schwab]

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.

[Martijn Lievaart]

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

[The Directive]

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

[Martijn Lievaart]

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

[Nick Hounsome]

"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