3

Case 1)

#define CONCATENATE(x,y) x##y

CONCATENATE(a,CONCATENATE(b,c)) gives aCONCATENATE(b,c).

Case 2)

 #define CONCATENATE(x,y) x##y
 #define CONCATENATE2(x,y) CONCATENATE(x,y)

CONCATENATE2(a,CONCATENATE2(b,c)) gives abc.

Why does case 1 doesn't work? And case 2 does?
Please explain through step-by-step procedure.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
chanzerre
  • 2,409
  • 5
  • 20
  • 28

2 Answers2

2

When macros are used in a self-referential way (or circularly), like you have for CONCATENATE, they are not recursively expanded. That's why:

CONCATENATE(a,CONCATENATE(b,c)) gives aCONCATENATE(b,c).

In the second case, the expansion of CONCATENATE2 is carried out after CONCATENATE is processed. Hence, you get the right output.

Self-referential usages of macros work fine for most cases. The exceptions are token pasting and stringification.

For example, if you have:

#define #define foo(x) int x

then,

foo(foo(x));

expands to:

int int x;

If you have:

#define STR(y) #y

then,

STR(STR(abcd));

expands to:

"STR(abcd)";

More details:

https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html

https://gcc.gnu.org/onlinedocs/cpp/Stringification.html#Stringification

How does the C preprocessor handle circular dependencies?

Community
  • 1
  • 1
R Sahu
  • 204,454
  • 14
  • 159
  • 270
  • The question is not about stringification, it's about token pasting. – John Bollinger Oct 09 '14 at 17:37
  • @JohnBollinger, stringification is only an example of using two layers of macros to achieve the right macro expansion and token pasting. – R Sahu Oct 09 '14 at 17:39
  • Ok, but the answer is nevertheless mistaken: a self-referrential macro is one where the macro name appears in its *definition*, not among its arguments. It works to recurse via arguments, as can be tested pretty easily. – John Bollinger Oct 09 '14 at 17:49
  • @JohnBollinger, I didn't say the macro is self-referential. I said it's used in self referential way. – R Sahu Oct 09 '14 at 17:54
  • it is true that when a macro's name appears within its definition, *those* apparent self-references are not expanded. HOWEVER, that rule does not apply when a macro *argument* contains a reference to the called macro. Normally in those cases, the argument IS expanded. Example: given `#define foo(x) int x`, `foo(foo(x))` expands to `int int x`, not `int foo(x)`. Try it. – John Bollinger Oct 09 '14 at 18:03
  • @JohnBollinger, thanks for clarifying. I looked up on the subject a bit more and updated my answer. – R Sahu Oct 09 '14 at 18:23
2

The GCC docs explain it this way:

Macro arguments are completely macro-expanded before they are substituted into a macro body, unless they are stringified or pasted with other tokens.

(emphasis added)

The operands of the ## (token pasting) operator, on the other hand, are not macro-expanded before being pasted together. So, given

CONCATENATE(a,CONCATENATE(b,c))

the preprocessor does not expand CONCATENATE(b,c) before expanding the outer macro's body because it is an operand of ##. The preprocessor instead performs token pasting before rescanning for more macros to expand, so

a ## CONCATENATE(b,c)

becomes

aCONCATENATE(b,c)

before the rescan, and there is no macro aCONCATENATE (but if there were, then it would be expanded).

On the other hand, with

CONCATENATE2(a,CONCATENATE2(b,c)),

the argument CONCATENATE2(b,c) is not an operand of the ## (or #) operator, so it is expanded before being substituted into the macro body, ultimately yielding

CONCATENATE(a, bc)

as the first expansion of the outer macro. That is rescanned for further expansions, yielding

abc
John Bollinger
  • 160,171
  • 8
  • 81
  • 157