Content deleted Content added
previous explanation was more accurate; the greedy algorithm isn't to blame for the definition of pp-number, just for not producing a valid parse instead |
→Internal consistency: compromise; the example is difficult to understand without some reference to scientific notation |
||
Line 122:
int sixteen = 0x3e-0x2e;
The reason is that <code>0x3e-0x2e</code> matches the form of a "preprocessing number" (since <code>e-</code> or <code>e+</code> can form part of a number in [[Scientific_notation#E_notation|scientific notation]]), and, since token-matching is greedy, is converted to a single preprocessing token. The subsequent conversion of that to a token in a later phase of translation is ill-defined, so the compiler will not obtain the intended tokenization of
int sixteen = 0x3e - 0x2e ;
even though spaces around the minus sign would not otherwise be required.
In practice, this general problem arises most commonly in the context of [[C++]] [[Template (programming)|templates]], where multiple closing angle brackets are incorrectly tokenized as the [[bit shift|right-shift operator]].
==Standardization==
| |||