|Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-13)|
|Re: Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-15)|
|Re: Preprocessing ## firstname.lastname@example.org (Kaz Kylheku) (2017-05-15)|
|Re: Preprocessing ## email@example.com (George Neuner) (2017-05-15)|
|From:||Hans-Peter Diettrich <DrDiettrich1@netscape.net>|
|Date:||Mon, 15 May 2017 11:28:46 +0200|
|Injection-Info:||miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8339"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||15 May 2017 10:46:40 EDT|
Am 13.05.2017 um 08:49 schrieb Hans-Peter Diettrich:
> How is the C preprocessor assumed to handle the ## concatenation operator?
> In the Windows headers I found macros like
> #define foo(x) bar(##baz(x))
> where an expansion into ... (baz ... doesn't make sense, because "(baz"
> is not a valid preprocessor token. Can somebody explain the meaning and
> handling of such constructs?
> [I would guess that some macro between ( and ## expanded to
The #define's leave no room for macros to the left of ##.
If, in above example, bar() were another macro, would the ## operator
stay literal part of the argument's token sequence?
#define bar(z) some_prefix z
would foo(suffix) expand into
> Or it could just be one of those text editing errors. -John]
Not here. A comment before a couple of such #define's suggests, that
they are a workaround for the lack of variadic macros ("..." arguments).
Return to the
Search the comp.compilers archives again.