is it ok to include a .c file in another .c file?

Question

For example:

file1.c has:

static const struct 
{ 
   int a;
   int b;
   int c;
} mystruct = { 1, 2, 3};

file2.c has:

#include <stdio.h>
#include "file1.c"

and so on.

Is this OK to do?

Answer 1

Is this ok to do? Please let me know. Thanks.

This will technically work, but I wouldn't recommend it. I would, instead, suggest putting your declarations in header files, and then just include both .c files in your project/makefile/etc.

This will be more of a "standard" means of working, which in turn makes your project more maintainable.

Answer 2

Yes, it is OK provided you have good motivations for it. For instance, it may help you to avoid source code duplication (even though you will still get duplication at the binary level), or it may allow you to work with pieces of code that are machine generated (e.g. a parser generated by a separate compiler). You may even get some performance or footprint improvements on some platforms because the compiler can select more optimized instructions (e.g relative, local calls in case file1.c includes code) that would not be otherwise possible if file1.c was a separate translation unit.

If your motivations are not good enough, it should be avoided, because it may cause troubles in a few areas. A few that comes to mind are:

• your build system may not be smart enough to detect that there is a dependency on file1.c
• your editor or development environment may not be smart enough to locate symbols from file1.c
• file1.c may cause linking errors if not all the symbols you define in it have internal linkage.

Answer 3

I would suggest that while there are times when it can be useful to #include a file which contains actual code or data definitions (as distinct from just declarations), I don't like to name files with a .c extension unless they are designed to be compiled directly. I generally name files which are designed to be #include'd, but which contain more than declarations, with a ".i" extension. For example, on one embedded processor I use, the code to access an element of a static structure is about a quarter the size of, and runs about four times as fast as, code to access an element given a structure pointer. Consequently, if there is a substantial block of code which would operate upon a structure, the code needs to run reasonably quickly, and there are two structures upon which the code might have to operate, it is more efficient to generate separate copies of the code for the two structures than to generate one copy of the code which can use either (if speed were not a concern, it would be possible have code which operates on one of the structures, along with a routine to swap the structures' contents. To operate on the second structure, swap the structures, operate on the first, and swap them back).

My preferred way to implement this idiom is to do something like:

#define THINGIE 0
#define THINGIE_STRUCT thingie0
#include "thingie.i"
#undef THINGIE_STRUCT
#undef THINGIE

#define THINGIE 1
#define THINGIE_STRUCT thingie1
#include "thingie.i"
#undef THINGIE_STRUCT
#undef THINGIE

A bit ugly, but sometimes worthwhile on machines which are very bad at indirect structure access.

Answer 4

Avoid doing this. Pull any type definitions and function signatures that will be useful/necessary to other parts of your project out of file1.c into a common header file than can be included in those other parts of your project.

Typically including file1.c in file2.c will work, since file inclusion is just that, replacing the #include with the contents of another file, but this will start to break as your project complexity increases, and you start having issues with multiply-defined symbols.

Answer 5

No, you always should avoid including a c file.

A header file should contain only definitions/prototypes.

A c file contains functions and should not be included.

Answer 6

Technically it's just the name of a file, the .c extension has no effect on the file contents, you could call it .z if you wanted to. So to answer your question: yes you can do it. But it does defy convention, and it should be inside a header file.

Answer 7

You can find a good answer to your question here:

Including one C source file in another?

I myself would save it as a header file, file1.h, and include that.

Answer 8

There are essentially no technical considerations here. That is, the decision has essentially nothing to do with the way software or hardware operates.

The considerations in this decision are human considerations. When we make decisions and create conventions about how we organize source code, we do so to achieve goals such as: Making code easier to write. Making code easier to maintain. Reducing mistakes.

These are human considerations. Humans behave in certain ways that differ from perfect machines: They make mistakes. They forget things. They work better with problems separated into pieces of manageable sizes.

Commonly, header files are used to declare things that are used in multiple source files (such as library routines that are used in many different programs by many different people) and to separate the declarations from definitions, so that you can compile a source file that uses routines without having to include the definitions of those routines in the source file. Technically, you could copy the declarations into each source file, and you would get the same result from the compiler. But this violates several goals: It makes the code harder to write, because, whenever there is a change to a routine definition, all the copies of the declaration have to be changed. And it increases errors: Sometimes, people will forget or miss one of the copies that needs to be changed.

So, you can put your definition of a struct object into a .c file. You can also put it into a header file. Will this help you achieve your goals?

Note that the struct object is declared static. If it is compiled in more than one source file, each object file that results will have a separate copy. When you link the object files into a single executable, it will have multiple copies of the same data (unless the developer tools you use are very, very good). That is a waste, so it would not be a good idea. However, if you are compiling it in only one source file, only the human considerations matter: Is there some chance you will make a mistake and compile both file1.c and file2.c? When other people work on this code, will they understand how and why mystruct is defined? And so on.

I have worked on projects where defining objects in separate source files is appropriate. For example, sometimes it is necessary to prepare a table of computed data and include it in the sources of a program. In such a case, keeping that table in a separate source file is reasonable.

Normally, the solution used in such a case is to use a source file that contains only the definition of the table and nothing else. In that source file, the table would be declared to be external, using the “extern” keyword. In a header file, the table would be declared but not defined. Each source file that uses the table would include the header file to declare the table. The source file that defines the table also includes the header file. (When you do that, if there is any mismatch between the header file and the source file, the compiler will complain. This avoids mistakes in the header file.)

The source file defining the table would be compiled into an object module. The source files containing other things for the program would be compiled into separate object modules. Then the linker is used to combine all the object modules into one program.

In your case, is there any reason for declaring the object to be static? If there is, then this solution of including its definition in another source file may be appropriate. However, it is rare for there to be such a reason. If you believe having the definition in a separate file is helpful to your organization of your sources, then it is more likely the appropriate solution is to declare the object to be external, as described above, and to compile the sources separately.

When using GCC, you can compile sources to object modules like this:

gcc -c -o name0.o name0.c gcc -c -o name1.o name1.c

The “-c” switch says “Just compile to object and stop, instead of doing the next step of linking to make an executable.“ The “-o ” switch specifies the name of the output file.

Then, you can link object modules to an executable like this:

gcc -o program name0.o name1.o