Re: Preprocessing ##

Kaz Kylheku <686-678-9105@kylheku.com>
Mon, 15 May 2017 13:41:08 +0000 (UTC)

          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)
Re: Preprocessing ## DrDiettrich1@aol.com.dmarc.email (Hans-Peter Diettrich) (2017-06-02)
| List of all articles for this month |
From: Kaz Kylheku <686-678-9105@kylheku.com>
Newsgroups: comp.compilers
Date: Mon, 15 May 2017 13:41:08 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 17-05-003
Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="8665"; mail-complaints-to="abuse@iecc.com"
Keywords: C, comment
Posted-Date: 15 May 2017 10:47:09 EDT

On 2017-05-13, Hans-Peter Diettrich <DrDiettrich1@netscape.net> wrote:
> 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?


According to ISO C, if the result of the ## operator is an invalid
token, the behavior is undefined.


If you're making a compiler which will have to handle the unmodified
header files from Microsoft platform development kits for Windows, you
have little choice but to implement compatible preprocessing, which
handles whatever constructs occur, in the same way.


In other words, the actual meaning here is "whatever Visual C does".
[Ugh. But I have to agree. -John]


Post a followup to this message

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