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