#include "*.c" ??

[John Smith]

I have a project that consists of about a dozen translation
units. I use a command line compiler and it occured to me that I
could simplify compiling the project by #include(ing) them in a
header that looks something like this:

/* project.h */
#include "aaa.c"
#include "bbb.c"
#include "ccc.c"
....

It works, but I never see it done. What are the pros and cons of
this sort of thing? Is there a practical reason not to do it?

JS

 

[Richard Tobin]

I have a project that consists of about a dozen translation
units. I use a command line compiler and it occured to me that I
could simplify compiling the project by #include(ing) them in a
header that looks something like this:

Surely you would include them in a .c file, not a .h file?

There are several reasons not to do this, but the most important is
that it doesn't always work. Files are an important scoping mechanism
in C, and putting everything in one file will break it: file-scope
static declarations of the same name will conflict.

Other reasons include being unable to re-use the compiled files
individually (either by linking against them directly or putting them
in a library), and the increased compilation time needed when a change
is made to one of the files.

If you find it tedious to type in the compilation commands, you should
be using something like "make" (there are versions for practically all
platforms).

-- Richard

 

[Gordon Burditt]

I have a project that consists of about a dozen translation

units. I use a command line compiler and it occured to me that I
could simplify compiling the project by #include(ing) them in a
header that looks something like this:

/* project.h */
#include "aaa.c"
#include "bbb.c"
#include "ccc.c"
...

It works, but I never see it done. What are the pros and cons of
this sort of thing? Is there a practical reason not to do it?

It doesn't always work. If you have static variables or static
functions, the names could conflict with names in other compilation
units. There are similar problems with #define s. Some of these
problems could be "silent", in that there are no compiler errors
or warnings, but the code doesn't work right.

You might have problems with several of the .c files including
the same header twice. This can often be fixed with "include guards".

You always have to recompile all of the files if you make any
change. This defeats utilities like "make" which only recompiles
stuff that has been modified.

You can't re-use a compiled object in more than one program.
It may be difficult to maintain the source so that the source
file can still be compiled separately if this isn't tested
regularly.

Gordon L. Burditt

 

[Michael Mair]

I have a project that consists of about a dozen translation units. I use
a command line compiler and it occured to me that I could simplify
compiling the project by #include(ing) them in a header that looks
something like this:

/* project.h */
#include "aaa.c"
#include "bbb.c"
#include "ccc.c"
...

It works, but I never see it done. What are the pros and cons of this
sort of thing? Is there a practical reason not to do it?

You already got some answers why not to do this.
There is _never_ a _good_ reason for "merging" two different
translation units like that.

Only #include header files unless you have reason to do
something different. I can only think of introducing template
functionality via including a "template" file(*) as a valid
reason -- and most people never see an example of this let
alone need it.


Cheers
Michael
___
(*): Essentially, you have a template file, e.g. foo.ct
which is intended to produce functions of a certain pattern,
for example:

-- usefoo.c --

#define FOO_NAME plusbar
#define FOO_PARM double bar
#define FOO_OP += bar

#include "foo.ct"

#define FOO_NAME assignbar
#define FOO_PARM double bar
#define FOO_OP = bar

#include "foo.ct"

.....

-- foo.c --
.....
void FOO_NAME (DataStructureType* pStartFrom, FOO_PARM)
{
/* sequence of complex filters in nested loops */
....
{ /* innermost block */
#ifdef FOO_OP
pCurrentElem->Data FOO_OP;
#elif ....
....
#endif
}
....
}

#ifdef FOO_OP
#undef FOO_OP
.....
#undef FOO_NAME
#undef FOO_PARM

 

[Thad Smith]

I have a project that consists of about a dozen translation units. I use
a command line compiler and it occured to me that I could simplify
compiling the project by #include(ing) them in a header that looks
something like this:

/* project.h */
#include "aaa.c"
#include "bbb.c"
#include "ccc.c"
...

It works, but I never see it done. What are the pros and cons of this
sort of thing? Is there a practical reason not to do it?

While I agree with the other comments that it's generally not a good
idea, there is at least one C dialect compiler that requires all code to
be in a single translation unit (it's easier to optimize for the limited
environment if you can see all the code at once). When using this, I
break code into modules the same as I do for other environments and
include them all in the top level project code file, where I hide other
non-standard features.