Ich habe eine seltsame Fehlermeldung von gtest erfahren. KompilierenWarum mag gtest meinen Ausdruck nicht?
EXPECT_EQ(MyVal,0xe-2);
Ergebnisse in Fehlermeldung:
unable to find numeric literal operator 'operator"" -2'
während
EXPECT_EQ(MyVal,0xe -2);
und
EXPECT_EQ(MyVal,0xf-2);
kompilieren in Ordnung. Irgendwelche Ideen? (Vielleicht versucht es zu potenzieren?)
Dies ist ein klassisches C/C++ Gotcha.
0xe-2 ist eine pp-number (Vorverarbeitung Nummer) Token, weil:
es beginnt mit einer Ziffer,
von Ziffern und Buchstaben besteht, mit Ausnahme von
ein - nach einem e.
So ist es ein einzelnes Token. Das Token entspricht jedoch keinem numerischen Literal, daher ist es nach der Vorverarbeitung kein gültiges Token.
dagegen 0xf-2 ist drei Token: 0xf, - und 2, und alle drei gelten nach der Vorverarbeitung.
Es ist immer besser, Leerzeichen um die Operatoren zu legen. Whitespace-Charaktere sind sehr erschwinglich.
Bis jetzt dachte ich, dass C++! Allgemein! ignoriert Leerzeichen. Wo kann ich die Fälle finden, wenn nicht? – katang
Danke, obwohl ich es nicht vollständig verstehe. Wenn es ein Token ist, warum sucht die Verarbeitung nach dem Operator? Wenn die Vorverarbeitung Ausnahmen wie 'e-2' berücksichtigt und das Ergebnis falsch ist; warum nicht versuchen, analog mit 'f-2' zu interpretieren? In der dargestellten Weise wird ein rechtlicher Ausdruck aufgrund eines inkonsequenten Präprozessors als falsch gewertet. – katang
Der Fehler 'literal operator "" 'bezieht sich auf eine C++ 11-Funktion, die benutzerdefinierte Literalkonvertierungsoperatoren erlaubt, bei denen es sich um Strings handelt, die an numerische Literale angehängt werden (wie die Längen- und Vorzeichen-Suffixe). Afaik, ein Literaloperator muss mit einem Buchstaben oder "$" beginnen, daher ist die Fehlermeldung etwas merkwürdig. Warum es nicht einen anderen lex versucht, ist die einzige Antwort "weil das ist, was der Standard sagt". C++ versucht jedoch nie, herauszufinden, was Sie gemeint haben könnten, also ist es konsistent. – rici