Macro arguments

[John]

Please, consider this macro:

#define mymacro(arg1, arg2) arg1 and arg2

Then it is used:

mymacro(boys, girls)

How is its expansion?

"boys and girls" or "boys and girls" ? <-(note the double space).
Is the space character preceding the "girls" token considered?
What's the general rule?

Regards.

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

Please, consider this macro:

#define mymacro(arg1, arg2) arg1 and arg2

Then it is used:

mymacro(boys, girls)

How is its expansion?

"boys and girls" or "boys and girls" ? <-(note the double space).
Is the space character preceding the "girls" token considered?
What's the general rule?

Regards.

Whitespace is eliminated during lexical analysis, as long as its not part of
a string, so I think this doesn't really matter.

 

[puppet_sock]

Please, consider this macro:

#define mymacro(arg1, arg2) arg1 and arg2

Then it is used:

mymacro(boys, girls)

How is its expansion?

"boys and girls" or "boys and girls" ? <-(note the double space).
Is the space character preceding the "girls" token considered?
What's the general rule?

In this particular case, I don't think it's significant. The compiler
is not going to be behaving differently due to the space being single
or double. All it does is mark the start/end of tokens. In the usual
case, you can insert as much white space as you like.

I suspect are asking this in order to get at some other issue.
For example, are you really trying to accomplish some kind of
concatenation of tokens thing? What are you trying to accomplish?
Socks

 

[Paul Mensonides]

Whitespace is eliminated during lexical analysis, as long as its not
part of a string, so I think this doesn't really matter.

No it isn't. Whitespace is significant until translation phase 7. However, the
preprocessor is allowed to compress non-newline whitespace sequences to a single
space character (see phase 3). In the case above, the whitespace has no
semantic effect even when stringized (because stringizing requires internal
whitespace to be condensed to a single space character). The only places
whitespace can matter, semantically speaking, is in the creation of string
literals or the creation of header-name preprocessing tokens. The following is
an example where the argument whitespace does change the result:

#define STR(x) #x

#define MACRO(arg) STR(+arg)

MACRO(123) // "+123"
MACRO( 123) // "+ 123"

The preprocessor is not allowed to insert whitespace anywhere, nor is allowed to
remove whitespace except in a very few specific places--in phase 3, the
preprocessor may compact whitespace; the preprocessor is required to remove
leading and trailing whitespace and condense internal whitespace when
stringizing; the preprocessor is required to remove whitespace preceding and
trailing the replacement list of a macro; and the preprocessor must ignore
whitespace between the stringizing operator (#) and its operand (i.e. # arg and
#arg are equivalent), between the token-pasting operator (##) and its operands
(i.e. a ## b and a##b, etc., are equivalent), and between the macro name (i.e.
specific identifier) and the argument list in a function-like macro invocation.

The preprocessor is not allowed to remove leading and trailing whitespace on a
macro argument, but in the above scenario, there is no semantic difference
except *maybe* in the production of an <h-char-sequence> header-name
preprocessing token, such as:

#define MACRO(arg1, arg2) <arg1 and arg2.h>

#include MACRO(boys, girls)
// <arg1 and arg2.h> or <arg1 and arg2.h> ?

However, in that case, the reinterpretation of a sequence to tokens produced by
macro expansion into a header-name preprocessing token is implementation
defined. As is how headers are found. So, the preprocessor is well within its
boundaries to produce either of the above results.

Regards,
Paul Mensonides