Der folgende Code wird in GCC und Clang kompiliert:
%Vor% Aber nicht das (Ersetzen von _a
mit _e
):
OTOH, dieser Code kompiliert:
%Vor%Was ist los?
(Diese Frage wurde von diesem GCC-Fehlerbericht inspiriert.)
Maximale Munch schlägt wieder.
[lex.pptoken] / p3:
Wenn der Eingabestream in Vorverarbeitungstoken bis zu a analysiert wurde gegebenes Zeichen:
- [zwei Ausnahmen sind hier nicht relevant]
- Andernfalls ist das nächste Vorverarbeitungstoken die längste Zeichenfolge, die ein Vorverarbeitungstoken bilden könnte, selbst wenn dies der Fall ist würde dazu führen, dass eine weitere lexikalische Analyse fehlschlägt, außer dass a header-name (2.8) wird nur innerhalb einer
#include
Direktive (16.2) gebildet.
Das Problem ist, dass 0e1_e+0
im Gegensatz zu 0e1_a+0
eine gültige Vorverarbeitungsnummer ([lex.ppnumber]) ist:
Als Ergebnis wird 0e1_e+0
als einzelnes pp-number Vorverarbeitungstoken analysiert und explodiert später, da es aus offensichtlichen Gründen nicht in ein gültiges Token konvertiert werden kann.
0e1_a+0
andererseits wird als drei Token analysiert, 0e1_a
, +
und 0
, und alles ist gut.
Tags und Links c++ c++11 user-defined-literals