Re: Preprocessing ##

Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Mon, 15 May 2017 11:28:46 +0200

          From comp.compilers

Related articles
Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-13)
Re: Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-15)
Re: Preprocessing ## 686-678-9105@kylheku.com (Kaz Kylheku) (2017-05-15)
Re: Preprocessing ## gneuner2@comcast.net (George Neuner) (2017-05-15)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@netscape.net>
Newsgroups: comp.compilers
Date: Mon, 15 May 2017 11:28:46 +0200
Organization: Compilers Central
References: 17-05-003
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8339"; mail-complaints-to="abuse@iecc.com"
Keywords: C
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?


[John]
> [I would guess that some macro between ( and ## expanded to
> nothing.


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?


E.g. with
      #define bar(z) some_prefix z
would foo(suffix) expand into
      some_prefix ##baz(suffix)
?


> 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).


DoDi


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.