Roman Mashak wrote:
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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
