The order of header inclusion

[Pavel]

I vaguely remembered reading something in the Standard while ago that
somehow discouraged the inclusion of user headers before Standard C++
Library headers. I tried to refresh my memory and looked up in the
Standard but could not find anything. Does anybody know any such
restriction/recommendation or has it never existed?

Thanks,
-Pavel

 

[Alf P. Steinbach]

* Pavel:

I vaguely remembered reading something in the Standard while ago that
somehow discouraged the inclusion of user headers before Standard C++
Library headers. I tried to refresh my memory and looked up in the
Standard but could not find anything. Does anybody know any such
restriction/recommendation

The usual recommandation is the opposite: to never include standard headers
before user headers.

The rationale is that one should to try to minimize the cases where something
works by accident.

Or at least, not let something work by accident when it's easy to avoid.

or has it never existed?

No.


Cheers & hth.,

- Alf

 

[Fred Zwarts]

I vaguely remembered reading something in the Standard while ago that
somehow discouraged the inclusion of user headers before Standard C++
Library headers. I tried to refresh my memory and looked up in the
Standard but could not find anything. Does anybody know any such
restriction/recommendation or has it never existed?

The rationale is probably that user headers could change the way the
standard headers are parsed, leading to unexpected and difficult to trace
behavior. This may happen e.g. if user headers (re)define macros.

 

[Pavel]

The rationale is probably that user headers could change the way the
standard headers are parsed, leading to unexpected and difficult to trace
behavior. This may happen e.g. if user headers (re)define macros.

Thanks Fred, also Ali and Hendrik,

I remember reading some reasoning similar to the one of Fred's. I
usually include standard C++ headers first, then standard C, then
platform, then 3rd-party libraries then company libraries/mine, and the
module's hearder at the end.

I have been doing it for decades and I was sure I was doing it for a
good reason -- I guess I need to re-think the whole thing on occasion.

Now the only reason I can think of is that the internals of "more
distant" files (standard etc) are less known to the programmer whereas
their interface (effect of inclusion) is probably better defined and
supposedly is kept to more rigorously. That is, the probability,
expected negative impact, detection cost and fixing cost of messing up
standard headers with my headers (or, especially unpleasant, with
3rd-party headers from some really large and complicated library) seem
to be all higher then those of messing up my headers (or 3rd-party
headers) with standard headers. Also, when standard headers can include
other standard headers, and there are #ifdef guards agains double
inclusion, including standard headers first would ensure lesser maximum
depth of inclusion.

The above is not a strong opinion, just trying to get together some pros
and contras now that I know my memory of the Standard recommendation was
all false.

-Pavel