Nachdem ich über das ärgerlichste Parse gelesen hatte, experimentierte ich ein wenig und fand dieses Programm. Es gibt zwei sehr ähnliche Linien. Einer von ihnen liefert Warnungen sowohl in g ++ 7 als auch in clang ++ - 3.9, ein anderer nicht.
%Vor% In der zweiten Zeile wird ein default-konstruiertes Objekt vom Typ int erstellt und sofort zerstört, also unbenutzt. Aber was passiert in der ersten Zeile? Wenn es auf die gleiche Weise geparst wurde, sollte dies ein Fehler sein, da es illegal ist, ein Objekt vom Typ void zu erstellen. Auf der anderen Seite sieht es auch nicht wie eine Funktionsdeklaration aus.
Es gibt keinen Unterschied beim Parsen. Beide Fälle werden durch simple-type-specifier abgedeckt, gefolgt von einer optionalen in Klammern gesetzten expression-list .
Die semantische Bedeutung ist in C ++ 17 (N4659) [expr.type.conv] / 2:
angegebenWenn der Typ cv
voidund der Initialisierer()ist, ist der Ausdruck ein prvalue des angegebenen Typs, der keine Initialisierung durchführt. Andernfalls ist der Ausdruck ein prvalue des angegebenen Typs, dessen Ergebnisobjekt direkt mit dem Initialisierer initialisiert wird.
Dies besagt ausdrücklich, dass void() ein Pr-Wert vom Typ void ist.
Nun bin ich mir sicher, dass es nicht beabsichtigt ist, dass ein Prvalue vom Typ void illegal ist, wie es üblich ist, z.B. (void)x; oder ruft eine void-Funktion auf!
Aber ich kann nicht finden, wo im Standard steht, dass die temporäre Materialisierung für void prvalues unterdrückt werden sollte. Die [class.temporary] / 2 scheint zu sagen, dass ein Ausdruck mit verworfenem Wert immer ein temporäres Material darstellt; und es ist ein Fehler, einen prvalue des unvollständigen Typs zu materialisieren. Vielleicht ist es ein Defekt im Standard.
Der Unterschied in der Warnung über "unbenutzter Wert" liegt wahrscheinlich darin, dass ein unbenutzter Wert des Typs void ein häufiges Vorkommen ist und es nicht hilfreich wäre, davor zu warnen.
Es wird auf die gleiche Weise geparst.
Warnungen kommen nicht vom Parser. Sie entstehen während der semantischen Analyse. Die SA bemerkte, dass ein Wert erstellt und von int(); zerstört wurde, ohne gelesen oder geschrieben zu werden.
Im Fall void gibt es keinen Wert, also keine Warnung.
Tags und Links c++ language-lawyer most-vexing-parse