Re^2: External (extra) files when using Inline::CPP

[afoken]

You can always just #include "filename.c" from the inline C code.

Most times, yes. But there are differences:

If you use #include "filename.c", static functions and variables in filename.c suddenly become visible in the inline C code, whereas they are separate and not visible from inline C code if you just link with filename.o. That means you can't have one static type1 foo(...) in filename.c and another static type2 foo(...) in inline C code if you use #include "filename.c", but it works fine if you compile and filename.c to filename.o and just link with filename.o.

Static variables are even worse. Two variables with equal name and type (one from inline C, one from filename.c) suddenly become one:

$ cat a.c
#include "b.c"

static int foo;

int main(int argc, char ** argv)
{
    foo=argc;   // dummy code
    return foo; // dummy code
}
$ cat b.c
static int foo;
$ cc -Wall -pedantic a.c
$

Note: no errors, no warnings.

$ cat a.c
#include "b.c"

static int foo;

int main(int argc, char ** argv)
{
    foo=argc;   // dummy code
    return foo; // dummy code
}
$ cat b.c
static int foo = 42;
$ cc -Wall -pedantic a.c
$

No errors, no warnings when initialized in one file.

$ cat a.c
#include "b.c"

static int foo = 42;

int main(int argc, char ** argv)
{
    foo=argc;   // dummy code
    return foo; // dummy code
}
$ cat b.c
static int foo = 42;
$ cc -Wall -pedantic a.c
a.c:3:12: error: redefinition of ‘foo’
    3 | static int foo = 42;
      |            ^~~
In file included from a.c:1:
b.c:1:12: note: previous definition of ‘foo’ with type ‘int’
    1 | static int foo = 42;
      |            ^~~
b.c:1:12: warning: ‘foo’ defined but not used [-Wunused-variable]
$

Both variables must be initialized to cause an error.

$ cc --version
cc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There i
+s NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PUR
+POSE.

$

Alexander

[NERDVANA]

That's a very nice illustration of my statement "The only reason to compile separate units is to prevent symbol collisions", but my point was that in a small enough amount of code written by one person, name collisions are not usually a problem.