Ein paar Fragen zum Standard



  • Hallo

    Ich arbeite gerade mit dem Standard von http://eel.is/c++draft/ aber ich finde ein paar Dinge gerade nicht. Vielleicht können mir die Standardprofis hier behilflich sein. 🙂
    1. Sei T ein Typ, dann ist T{} ja ein prvalue unabhängig von der Wahl von T . Wieso kann ich diesen prvalue verändern und ihm sogar etwas zuweisen? Für fundamentale Typen funktioniert das nicht, für Klassen-Typen schon.
    2. Sind Programme, die undefined behavior erzeugen, ill-formed? Oder sind sie weder well-formed noch ill-formed?
    3. Ich verstehe unsequenced aber ich finde die Stelle nicht, wo Funktionsargumente als unsequenced spezifiziert werden. Wo steht das?

    LG



  • Fytch schrieb:

    1. Sei T ein TypObjekttyp, dann ist T{} ja ein prvalue unabhängig von der Wahl von T . Wieso kann ich diesen prvalue verändern und ihm sogar etwas zuweisen? Für fundamentale Typen funktioniert das nicht, für Klassen-Typen schon.

    Prvalues eines Klassentyps T sind temporäre Objekte, die irgendwo im Speicher liegen. Die kann man verändern. Der automatisch generierte Zuweisungsoperator hat die Signatur T& operator=(const T&); , was ein rvalue auf der linken Seite des Zuweisungsoperators zulässt – genauso wie bei allen anderen Elementfunktionen, die das nicht explizit durch ab C++11 verfügbare "ref-qualifier" verbieten.

    (Achtung: Objekttyp = Möglicher Typ eines Objektes im Sinne der Objekt-Definition des Standards, wo es eigentlich nur um Datenspeicher geht. Mit Objekttyp sind nicht unbedingt Instanzen von Klassentypen gemeint. Klassentypen sind Typen, die mit class, struct oder union deklariert werden.)


  • Mod

    Fytch schrieb:

    2. Sind Programme, die undefined behavior erzeugen, ill-formed? Oder sind sie weder well-formed noch ill-formed?

    Sie können das eine oder das andere sein, allerdings bedingt jedes Programm, das ill-formed ist, notwendigerweise undefined behavior, falls es zur Ausführung kommt.

    Fytch schrieb:

    3. Ich verstehe unsequenced aber ich finde die Stelle nicht, wo Funktionsargumente als unsequenced spezifiziert werden. Wo steht das?

    Das ist ab C++17 nicht mehr der Fall. Siehe 8.2.2/5


  • Mod

    Wieso kann ich diesen prvalue verändern und ihm sogar etwas zuweisen? Für fundamentale Typen funktioniert das nicht, für Klassen-Typen schon.

    Prvalues sind nicht per se const . Zuweisungen an prvalues fundamentaler Typen machen wenig Sinn, weil das Ergebnis doch einfach der zugewiesene Wert wäre, und es bis auf die Seiteneffekte des prvalues keinen Unterschied macht. Das ist also eine der wenigen Situationen in der Sprache, in denen "guter Stil" durch Beschränkungen forciert wird. Zuweisungen an Klassen prvalues machen durchaus Sinn, dadurch lassen sich einige Idiome implementieren; Es würde mehr schaden, das zu verbieten, als nicht.

    Fytch schrieb:

    2. Sind Programme, die undefined behavior erzeugen, ill-formed? Oder sind sie weder well-formed noch ill-formed?

    Sie können well-formed sein. Oder keines von beiden. Der status quo ist, dass bestimmte Formen von undefined behavior zur Laufzeit auftreten, dann kann das Program well-formed sein, aber das Verhalten der abstrakten Maschine, unter der das Program ausgeführt wird, ist es nicht. Es kann auch undefined behaviour zur Übersetzungszeit geben, bspw. im Rahmen des Präprozessors (siehe [cpp]), dann ist das Verhalten der Implementierung nicht definiert. Dazu gibt es noch ill-formed NDR, welches quasi mit compile time undefined behavior identisch ist.

    3. Ich verstehe unsequenced aber ich finde die Stelle nicht, wo Funktionsargumente als unsequenced spezifiziert werden. Wo steht das?

    Siehe die Notiz in [expr.call]. Es ist implizit durch [intro.execution]/17 gegeben.



  • Danke euch allen dreien. Sehr gute Erklärungen, ich hab's nun verstanden.

    LG


Anmelden zum Antworten