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
BecauseThe ANSIreason Cis provides support for [[Scientific_notation#E_notation|scientific notation]],that <code>e0x3e-0x2e</code> ormatches <code>e+</code>the is allowed as partform of a "preprocessing number", by the preprocessor. and, Sincesince token-matching is greedy, <code>0x3e-0x2e</code> is converted to a single preprocessing token. However, because of the mix of [[floating-point]] and [[hexadecimal]] notation, theThe subsequent conversion of that to a token in a later phase of translation is ill-defined. In this particular case, spaces around the minus sign must be added so the compiler canwill not obtain the intended tokenization: of
int sixteen = 0x3e - 0x2e ;
even though whitespacespaces 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]].
