Including multiple .c files in a single translation unit

Question

In C is it recurrent to have .c files including other internal .c files with static variables / functions in a copy / paste manner? Like a .c file composed of many .c files where you want everything to be kept private and not declared in a header file.

Example:

a.c

static int a() {
    return 3;
}

b.c

static int b() {
    return 6;
}

c.h

int c();

c.c

#include "c.h"

#include "a.c"
#include "b.c"

int c() {
    return a() + b();
}

main.c

#include <stdio.h>

#include "c.h"

int main() {
    printf("%d\n", c())
}

To compile

clang -c c.c
clang -c main.c
clang c.o main.o -o test.exe

Including source files is not common. If you want to do some "private" declarations or structure definitions etc. that are shared between some but not all source files of your project, then create a second header files for that. There's nothing stopping you from having `c.h` and `c_private.h`. — Some programmer dude, Feb 23 '21 at 12:49
Fyi, `#include "anything.c"` is an *automatic* design smell. When you state "where you want everything to be kept private", it's a full-on contradiction to your design. The content of both a.c and b.c was sucked into c.c just by `#include`. So much for "private". Nothing prevents anyone else from doing the *exact* same thing. — WhozCraig, Feb 23 '21 at 12:50
If you're `#include`ing a .c file, you're doing it wrong. The language is not stopping you from doing that, but it's not the usual convention. And if you ever want to work with others on a larger project, you should learn the more conventional ways of doing things. — dratenik, Feb 23 '21 at 12:50
What if a `.c` file becomes too large and you just want to separate it in multiple files to make it more clear? — João Pires, Feb 23 '21 at 12:56
Then do what you already do: Build separate source files as separate translation units into separate object files, which you then link together. — Some programmer dude, Feb 23 '21 at 12:58
@Someprogrammerdude, in my case I just really want to join multiple `.c` files exposed by a single header all belonging to a single translation unit. — João Pires, Feb 23 '21 at 13:20
There's nothing preventing you from having multiple translation units that provide definitions for functions that are all declared in a single header file. — William Pursell, Feb 23 '21 at 16:20
That's what [Berkley](https://opensource.apple.com/source/Libc/Libc-167/gen.subproj/i386.subproj/strlen.c.auto.html) does. Before refactoring, the code can get long; in this case, I'd prefer `static` functions in separate files be named `.h`. — Neil, Feb 23 '21 at 20:32

score 0 · Answer 1 · answered Feb 23 '21 at 15:15

Nope, this is not common. The standard way is to create new header files for a.c and b.c and include those instead of .c source files but otherwise as you did. Then you compile all sources separately and link them together, in your case:

clang -c a.c
clang -c b.c
clang -c c.c
clang -c main.c
clang a.o b.o c.o main.o -o test.exe

score 0 · Answer 2 · answered Feb 23 '21 at 16:04

if you Rename a.c to a.h, b.c to b.h, then everything looks normal.

#include is preprocess of the compiler; it just insert the content of the target file there. no matter is .h or .c or something else.

But in convention, it not good to include the implementation file. which will ruin the source code structure.

Including multiple .c files in a single translation unit

2 Answers2