Physical Location of #define Symbols

[JustBoo]

Whilst reading through the C++ FAQ. I came across Section 29.8 and
realized I never had fully thought about where a #define resided in a
Standard C++ program.

I thought they were a compile-time entity where the preprocessor
"searched and replaced" the "symbol" with the literal value that had
been assigned with the #define.

From the FAQ, Section 29.8
<quote>
Every #define macro effectively creates a new keyword in every source
file and every scope until that symbol is #undefd. The preprocessor
lets you create a #define symbol that is always replaced independent
of the {...} scope where that symbol appears.
</quote>

Is this only at compile time? Are all #defines put into a global
symbol table? Or... ?

I guess I've been working from a "rote mode" all these years in regard
to #defines. (Which are evil.) :-)

PS: I tried many search term permutations in Google with this and
literally none were less than 2 million hits. Too much can be the
same as none at all. :-)

Thanks in advance.

[Shark]

>Is this only at compile time? Are all #defines put into a global

symbol table? Or... ?

IIRC #define does not go into the symbol table. Something I read along
these lines in Effecive C++ by Scott Meyers. You can't dereference a
defined name. The pre processor replaces every #define with something
it likes or prefers.

[TB]

Shark sade:

Is this only at compile time? Are all #defines put into a global
symbol table? Or... ?

IIRC #define does not go into the symbol table. Something I read along
these lines in Effecive C++ by Scott Meyers. You can't dereference a
defined name. The pre processor replaces every #define with something
it likes or prefers.

After lexical translation phase 4, #define symbols are no longer needed,
and can be discarded.

--
TB @ SWEDEN

[mlimber]

Shark wrote:

Is this only at compile time? Are all #defines put into a global
symbol table? Or... ?

IIRC #define does not go into the symbol table. Something I read along
these lines in Effecive C++ by Scott Meyers. You can't dereference a
defined name. The pre processor replaces every #define with something
it likes or prefers.

The preprocessor does text substitution, and then it's output is passed
to the compiler. No symbols are retained. So, for instance, all
#include statements are replaced with the contents of the specified
file, and all #defines are substituted whenever the specified token is
found. Every compiler I've used has had a switch to output the
preprocessed file that would be passed to the compiler so that the
programmer can verify exactly what substitutions took place.

Cheers! --M

[Thomas Tutone]

JustBoo wrote:

Whilst reading through the C++ FAQ. I came across Section 29.8 and
realized I never had fully thought about where a #define resided in a
Standard C++ program.

I thought they were a compile-time entity where the preprocessor
"searched and replaced" the "symbol" with the literal value that had
been assigned with the #define.
I believe that is essentially correct - the preprocessor engages in
simple textual substitution.

From the FAQ, Section 29.8
<quote>
Every #define macro effectively creates a new keyword in every source
file and every scope until that symbol is #undefd. The preprocessor
lets you create a #define symbol that is always replaced independent
of the {...} scope where that symbol appears.
</quote>
I think the key word in the above quotation is "effectivel y." Every
define macro _effectively_ creates a new keyword ... independent of the
{...} scope where the symbol appears.
Is this only at compile time? Are all #defines put into a global
symbol table? Or... ?

Only at compile time.

Best regards,

Tom

[JustBoo]

On 16 Jan 2006 14:01:11 -0800, "Thomas Tutone"
<Th***********@ yahoo.com> wrote:

JustBoo wrote:

I thought they were a compile-time entity where the preprocessor
"searched and replaced" the "symbol" with the literal value that had
been assigned with the #define.

I believe that is essentially correct - the preprocessor engages in
simple textual substitution.

Okay, from your response and others I can rest easy. :-)

As I though, the compiler holds/saves the "symbols" during the
preprocessor phase, uses them, then releases them when done.
All during compile time.

To mlimber: Got it. :-) In the good ol' bad ol' days when I first
learned C++ with Borland's TurboC++ I remember there was an
option on a main menu dropdown that allowed one to view the
preprocessor output. It was quite instructive.

I don't remember it being such a prominent feature on any other
compiler since.

Thanks to all who responded.
--
Not all those who wander are lost. - J.R.R. Tolkien

[Thomas Tutone]

JustBoo wrote:

To mlimber: Got it. :-) In the good ol' bad ol' days when I first
learned C++ with Borland's TurboC++ I remember there was an
option on a main menu dropdown that allowed one to view the
preprocessor output. It was quite instructive.

I don't remember it being such a prominent feature on any other
compiler since.

<Implementati on Specific>

Not sure if this is what you are referring to, but using gcc (and I
imagine most other compilers), one can run the preprocessor without
compiling the resulting code. In other words, ordinarily when one
compiles, what actually happens is the preprocessor first preprocesses
the code (brings in any #include files, strips out the comments, makes
the #define substitutions, etc.), then feeds the result into the
compiler. On gcc, one can call the preprocessor by itself by executing
cpp (rather than gcc or g++) at the command line. Looking at the
result can be very instructive, since it now reflects the result of all
the macro substitution. The result also tends to be very long if your
file #include's any system headers.

Of course, you might not characterize that feature as being as
"prominent" as it was on TurboC++

</Implementation Specific>

Best regards,

Tom

[JustBoo]

On 16 Jan 2006 16:12:41 -0800, "Thomas Tutone"
<Th***********@ yahoo.com> wrote:

[snipped good explanation]

Of course, you might not characterize that feature as being as
"prominent" as it was on TurboC++

And you would be correct. :-) Not being as easy to use I don't use it
as much. "No excuse!" I know....

However beautiful the strategy, you should occasionally
look at the results. - Winston Churchill <grin>