Let's say we have 2, C code files namely file1.c and file2.c.
file1.c contains few pre-processor definations
say #define TEST1 10
We now compile file1.c , make it's object file.
So far so good....
and use this object file in the other file i.e file2.c.
This makes no sense. You cannot use the output of the compiler
as an input to file2.c -- that is:
% cat file1.c
#define TEST1 10
int f(void) { return TEST1; }
% cat file2.c
#include "file1.o"
...
is unlikely to work.
Then can we use the macro TEST1 in file2.c as well.
You can define TEST1 separately in file2.c:
#define TEST1 zorgleblatt
This is generally a bad idea, because now you have two different
things named TEST1, and two different expansions. When you go
to talk to the programmer in the next cubicle and start talking
about the TEST1 macro, he may think you mean the *other* TEST1
macro.
Even if you define it as the same thing:
#define TEST1 10
it remains error-prone, as a change to one of the definitions
will not affect the other one.
This is why Ken, Dennis, and Brian provided "header files". Put
the define in a separate, third file -- named "test1.h" for instance
-- and use "#include" directives in file1.c and file2.c to include
the third, shared file.
As I understand about macros, they are replaced by their
corresponding values, but are the definations removed from the
source files , once the preprocessor scans the file.
The *source* files are not modified by compilation (at least, not
on any sane system). The macros are, however, expanded lexically
at the point they are encountered, in Phase 4 of translation (see
the C standard, "translation phases"). This happens on a
"per-translation-unit" basis.
Compilers are not required to (and many do not) retain any information
about preprocessor macros in the object files produced by Phase 7.
Final executable programs are produced by Phase 8.
Note that phases 1 through 4 are often collectively referred to as
"preprocessing", phases 5 through 7 are often referred to as
"compiling", and phase 8 is typically referred to as "linking".
These have a historical basis: in Dennis's original C compilers,
phases 1 through 4 were implemented by a program called "cpp" (the
"C PreProcessor"), 5 through 7 by the compiler proper[%], and 8 by
the linker/loader "ld". In some compilers, Phase 7 was split into
two or three programs. But as far as the C standard is concerned,
these are all just parts of "translating" C code into something
that is actually run by an "implementation".
[% Technically, Dennis's original C compilers did not even do
some of these -- for instance, there was no adjacent string
literal concatenation.]
