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) |
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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.