Unspecified evaluation order of stringize operators

357 views Asked by At

Unary operators are typically parsed with higher precedence than binary operators, and when scanning left-to-right a prefix operator will be found first. So why is the order of evaluation of stringize (#) operators unspecified with respect to concatenation (##) operators? Does order of evaluation mean something different from precedence in the context of [cpp.stringize] ยง16.3.2?

(The preprocessor has no side effects, so technically it has no such thing as order of evaluation.)

And how does the text "replaced by a single character string literal preprocessing token that contains the spelling of the preprocessing token sequence for the corresponding argument" jibe with other precedence, given that any alternative would stringize the result of concatenation, not the argument per se?

Does any implementation do something funny, or could the order of evaluation text be safely removed and replaced with "The # operator has higher precedence than the ## operator"?

This question is cross-posted to the std-discussion mailing list, but please prefer to reply here.

Note: I plan to draft an official proposal to revise this part of the C++ specification, so please share your knowledge! The underlying motivation is to make the preprocessor more deterministic.

1

There are 1 answers

7
Potatoswatter On

I hope to see another answer, but following @R's comment I'm leaning toward the opinion that the standard means exactly what it says. Due to absence of side effects, the order of evaluation has no effect in the preprocessor, so it shouldn't be specified. Precedence and associativity of # and ## should be specified, but are omitted from the standard.

Each of the terms associativity, precedence, and order of evaluation has a mutually exclusive meaning and the standard should be above confuting them.

Edit: I've formally proposed to resolve this. (See section 5.1.)