typical practise for #include's

[Roman Mashak]

Hello, All!

I wonder are there any typical, common used practises to organize all
#include's in the large/medium size project. Try to explain what I mean:
suppose I have three tranlsation units in project and correspondent header's
with functions declarations, typedefs and etc.:

unit1.c, unit1.h
unit2.c, unit2.h
unit3.c, unit3.h

In my opinion it would be very simple to make ONE big header, call it
defs.h, which include in every unit's header file. That defs.h would include
all important headers (suppose stdio.h, stdlib.h, string.h, errno.h so on)
and also some macros, variables, types. It seems fine, except the issue that
some of these headers might be useless in other translation units, though
preprocessor will process it.

Hopefully my explanation is comprehensible

With best regards, Roman Mashak. E-mail: (e-mail address removed)

 

[Michael Mair]

Hello, All!

I wonder are there any typical, common used practises to organize all
#include's in the large/medium size project. Try to explain what I mean:
suppose I have three tranlsation units in project and correspondent header's
with functions declarations, typedefs and etc.:

unit1.c, unit1.h
unit2.c, unit2.h
unit3.c, unit3.h

In my opinion it would be very simple to make ONE big header, call it
defs.h, which include in every unit's header file. That defs.h would include
all important headers (suppose stdio.h, stdlib.h, string.h, errno.h so on)
and also some macros, variables, types. It seems fine, except the issue that
some of these headers might be useless in other translation units, though
preprocessor will process it.

Hopefully my explanation is comprehensible

I am not sure whether this is topical round here.

Depending on your build system, your scheme can create
unnecessary compile dependencies -- every time one of the
headers included in defs.h is changed, all translation units
directly or indirectly including defs.h are considered "dirty"
and need to be recompiled; if you have medium size project (I
think of "in the range from 50,000 through 500,000 LoC") or
larger, then this may increase turnaround times to the point
where they become unsufferable even with shared build systems.

Apart from that, the individual compile times may be increased
if literally hundreds of unnecessary header files are part of
every translation unit.

However, this also depends on the structure of your project.

If you have many similar modules, comparable to implementations
of "child classes" (yes, there is no such thing in C but the
analogy is easier than describing everything around it), then
it may make sense to create one central header for _internal_
use of these modules i.e. to be included only directly in
translation units.


Cheers
Michael

 

[rziak]

Hello, All!

I wonder are there any typical, common used practises to organize all
#include's in the large/medium size project. Try to explain what I mean:
suppose I have three tranlsation units in project and correspondent header's
with functions declarations, typedefs and etc.:

unit1.c, unit1.h
unit2.c, unit2.h
unit3.c, unit3.h

In my opinion it would be very simple to make ONE big header, call it
defs.h, which include in every unit's header file. That defs.h would include
all important headers (suppose stdio.h, stdlib.h, string.h, errno.h so on)
and also some macros, variables, types. It seems fine, except the issue that
some of these headers might be useless in other translation units, though
preprocessor will process it.

Hopefully my explanation is comprehensible

With best regards, Roman Mashak. E-mail: (e-mail address removed)

This seems like scheme Microsoft is using by default in their compilers.
Only they call your "defs.h" as "stdafx.h".

This technique is very effective for generating precompiled headers,
because compiler parses all those headers only once for entire project.

Depends if your compiler supports this method or not. But generally do
not be too concerned with including few thousand lines <stdio.h>
somewhere where it is not needed because time for compilation of file
that small is negligent (few milliseconds on modern machines).

The problem I would like to point out for you is that you get your
global namespace and macro namespace polluted much more this way. Think
how many C programmers use common word macros in place of constants and
inline functions. Or all those IN and OUT macros, Abort or GetTime function.