Order of preprocessor macro replacement

S

Shriramana Sharma

Hello. I found that the C standard prescribes that once a translation unit has undergone macro replacement once, it will be rescanned for further macros to be replacement and again and again until there are no more macros to replace.

Due to this rescanning, I can write:

# define MyInt int
# define int short
MyInt a ;

or:

# define int short
# define MyInt int
MyInt a ;

and in both cases the final output of the preprocessor is:

short a ;

My question is: in which of the above inputs i.e. later definition modifies output of earlier definition or vice versa would the preprocessor arrive at "no more macros to replace" status quicker?
 
E

Eric Sosman

Hello. I found that the C standard prescribes that once a translation unit has undergone macro replacement once, it will be rescanned for further macros to be replacement and again and again until there are no more macros to replace.

Due to this rescanning, I can write:

# define MyInt int
# define int short
MyInt a ;

or:

# define int short
# define MyInt int
MyInt a ;

and in both cases the final output of the preprocessor is:

short a ;

Aside: You shouldn't #define keywords. If you do so before
#include'ing any standard header or before expanding any macro
#define'd by a standard header, the outcome is undefined (7.1.2p4).
That is, after `#define int short' you must not

1) #include any standard header whatsoever, or
2) invoke any macro #define'd by a standard header

Note that since the standard headers may declare "masking" macros
for any or all standard library functions, you cannot even call
sqrt(x); you must write (sqrt)(x) or use some other subterfuge to
avoid the possibility of a macro expansion.

In brief: Don't Do That.
My question is: in which of the above inputs i.e. later definition modifies output of earlier definition or vice versa would the preprocessor arrive at "no more macros to replace" status quicker?

"Quicker" would be a function of the particular compiler, and
of its internal algorithms for recognizing, expanding, and rescanning
macros. Both formulations require two recognize/expand operations.
If your question is "Is the second equivalent to `#define MyInt short'"
the answer is "No," as you can demonstrate with

#define int short // Don't Do That
#define MyInt int
MyInt a;
#undef int
MyInt b;
#define int zaphod // Don't Do That
MyInt c;

*My* question would be: Why do you care?
 
K

Keith Thompson

Shriramana Sharma said:
Hello. I found that the C standard prescribes that once a translation
unit has undergone macro replacement once, it will be rescanned for
further macros to be replacement and again and again until there are
no more macros to replace.

Due to this rescanning, I can write:

# define MyInt int
# define int short
MyInt a ;

or:

# define int short
# define MyInt int
MyInt a ;

and in both cases the final output of the preprocessor is:

short a ;

My question is: in which of the above inputs i.e. later definition
modifies output of earlier definition or vice versa would the
preprocessor arrive at "no more macros to replace" status quicker?

Your compiler will spend far less time processing the macro expansions
than you've spent wondering about it.
 
W

Walter Banks

Shriramana said:
Hello. I found that the C standard prescribes that once a
translation unit has undergone macro replacement once,
it will be rescanned for further macros to be replacement
and again and again until there are no more macros to replace.

Due to this rescanning, I can write:

# define MyInt int
# define int short
MyInt a ;

or:

# define int short
# define MyInt int
MyInt a ;

and in both cases the final output of the preprocessor is:

short a ;

My question is: in which of the above inputs i.e. later
definition modifies output of earlier definition or vice versa
would the preprocessor arrive at "no more macros
to replace" status quicker?

It really doesn't matter. The definitions are stored before
MyInt a; is expanded and it is essentially expanded left
to right is a single pass by the compiler as it is fetching
new tokens from the input. In our compilers definition
order is unimportant.

Definitions are not pre expanded, as obvious as that
is as a compiler optimization everyone (including me)
who has written compilers eventually learn that it is a
bad idea.

w..
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top