|Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-13)|
|Re: Preprocessing ## DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-15)|
|Re: Preprocessing ## email@example.com (Kaz Kylheku) (2017-05-15)|
|Re: Preprocessing ## firstname.lastname@example.org (George Neuner) (2017-05-15)|
|Re: Preprocessing ## DrDiettrich1@aol.com.dmarc.email (Hans-Peter Diettrich) (2017-06-02)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com.dmarc.email>|
|Date:||Fri, 2 Jun 2017 08:04:48 +0200|
|Injection-Info:||miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="11241"; mail-complaints-to="email@example.com"|
|Posted-Date:||05 Jun 2017 01:49:33 EDT|
Am 15.05.2017 um 17:31 schrieb George Neuner:
> On Sat, 13 May 2017 08:49:36 +0200, Hans-Peter Diettrich
> <DrDiettrich1@netscape.net> wrote:
>> How is the C preprocessor assumed to handle the ## concatenation operator?
> It concatenate tokens *prior* to expansion. If the token references a
> parameter of the current macro, the (text of the) parameter is
> substituted, otherwise the token is simply copied.
In a newer draft I found the constraint, that ## is an operator only if
present in the replacement list (macro body), not from an argument.
>> In the Windows headers I found macros like
>> #define foo(x) bar(##baz(x))
Here the constraint is violated, ## is part of the argument and thus not
recognized as a preprocessor operator.
>> [I would guess that some macro between ( and ## expanded to
>> nothing. Or it could just be one of those text editing errors. -John]
> I think John probably is correct that you've found typos. If it were
> the result of a macro substitution, you would see it only in the
> output of the preprocessor - it would not be visible in an input
> header file.
In the meantime I guess that this construct is a creative use of the
preprocessor, when *also* used for some other postprocessor. The C
compiler may never see the ## if bar(x) has an empty definition, with
the argument unused. This seems to be the case with above example,
unless a project or tool adds global definitions which result in a
different definition of bar(x).
The standard also includes an example
#define hash_hash # ## #
which expands into a new ## token, which *is not* the ## operator. This
may or may not mean that ## is recognized and handled as a preprocessor
operator *only if* it occurs in the replacement list (body) of a macro
definition. Such a token is not accepted subsequently by a C compiler,
but may be recognized by some other tool. Likewise the standard requires
that a # operator must be followed by a macro argument, else it is not
recognized as a preprocessor operator. This signals to me that the
preprocessor is allowed to output token sequences which are not valid C
code, but may be valid when processed by some other tool.
> Moreover, although I'm not 100% certain, I believe the preprocessor
> does not substitute inside (it's own) preprocessor definitions, but
> rather only substitutes into C code.
Right, immediate evaluation of # ## #, as a constant expression during
macro definition, would result in a new ## token inside the replacement
list, which would be recognized as another ## operator during a
subsequent macro expansion. This were not the behaviour indicated by the
description of above example.
Thanks for your comments, without which I e.g. had guessed that constant
expression evaluation were allowed during macro definition.
Return to the
Search the comp.compilers archives again.