rvalue reference

[otze]

Sone schrieb:

otze schrieb:

Irgendwie zweifel ich an einem Sprachstandard, den man fast wortwörtlich auswendig lernen muss, dmait man das Verhalten der Sprache interpretieren kann.

Deswegen ist C++ nur für die Verrückten.

03 war noch lange nicht so schlimm wie 11.

[zjraw]

otze schrieb:

03 war noch lange nicht so schlimm wie 11.

Gilt genauso für C++03.

struct A
{
  A(){std::cout << "C";}
  ~A(){std::cout << "D";}
};

A const& hi(A const& a)
{
  return a;
}

int main()
{
  {
    A const& i = hi(A());
    std::cout << " hi ";
  }
  std::cout << "\n--\n";
  {
    A const& i = static_cast<A const&>(A());
    std::cout << " hi ";
  }
}

/* Ausgabe:
CD hi
--
C hi D
*/

Ich verstehs aber immer noch nicht. Damit wäre nämlich static_cast tatsächlich anders als move.

[Sone]

Da wird wohl einfach der Compiler falsch liegen. Genau wie selbst die neuste veröffentlichte Variante des GCCs nicht standardkonform ist. Ich würde es auf 4.9 testen, bin aber zu faul um umzubooten.

Hast du obiges Beispiel auf Clang getestet?

03 war noch lange nicht so schlimm wie 11.

Auch C++03 hatte seine Hardcore-Teile.

[zjraw]

Sone schrieb:

Hast du obiges Beispiel auf Clang getestet?

Auf g++ 4.9 sowie auf clang 3.4. Verhält sich aber auch auf älteren Versionen so.

[Sone]

Wenn das tatsächlich nicht konform ist, dann müsste man beiden Compilern ein Ticket schreiben.

[otze]

Sone schrieb:

Auch C++03 hatte seine Hardcore-Teile.

Aber irgendwie wurden das mit C++11 nur mehr, nicht weniger. Dieser ganze RValuee kram ist ohne Standard lesen nicht ordentlich erklärbar, weil es da echt um details geht.

[Sone]

otze schrieb:

Sone schrieb:

Auch C++03 hatte seine Hardcore-Teile.

Aber irgendwie wurden das mit C++11 nur mehr, nicht weniger.

Richtig, also wie ich sagte, C++ ist für Verrückte. Ich dachte zuerst, 10-15 Jahre? Die spinnen! Das schaff' ich in Fünf.

Jetzt bin ich genau zweieinhalb dabei, und es gibt kein Ende. Nein, desto mehr ich um mich sehe, öffnen sich mir die Augen. Mit C++14 und 17 wird es noch ein wenig mehr. Dabei ist C++11's Move-Semantik an sich doch so intuitiv...

Dieser ganze RValuee kram ist ohne Standard lesen nicht ordentlich erklärbar, weil es da echt um details geht.

Deswegen strenge ich mich auch so an, alles durch den Standard zu erklären. Nur ist das so frickelig. Da ist Sutter bspw. eine gute Quelle. Denn wer ist besser als der, der weiß, was die Paragraphen eigentlich bedeuten?

Oder camper, der Überflieger.

[otze]

Sone schrieb:

Deswegen strenge ich mich auch so an, alles durch den Standard zu erklären.

Das machts aber nicht besser, weil man dann den Standardtext verstehen muss. Und dann redet man auf einmal über l,r,pr,xl,gl values. wtf?!?

[Sone]

otze schrieb:

Und dann redet man auf einmal über l,r,pr,xl,gl values. wtf?!?

Das ist ja noch gar nichts, und die Begriffe sind doch eigentlich selbst redend. Es gibt drei Grundarten von Ausdrücken - lvalues: Das sind alle Objekte/Referenzen mit Namen und alle lvalue-Referenzen,
xvalues sind alle unbenannten rvalue Referenzen und Ausdrücke damit (wie Member von denen usw.),
und prvalues sind alle Namenlosen Objekte (bspw. Temporaries).

Also ist die Faustregel: Alles mit einem Namen resultiert in einem lvalue als Ausdruck, und alles unbenannte außer lvalue-Referenzen ist ein rvalue.

Und bei deiner Aufzählung muss das l vom x weg.

[zjraw]

Sone schrieb:

die Begriffe sind doch eigentlich selbst redend.

Aha

lvalues: Das sind alle Objekte/Referenzen mit Namen und alle lvalue-Referenzen,

Also sind enum-Konstanten lvalues.

xvalues sind alle unbenannten rvalue Referenzen und Ausdrücke damit (wie Member von denen usw.),

Wie soll man das verstehen ohne zu wissen, was ein rvalue ist?
Also:

string s;
return s; // <-- s ist kein xvalue

prvalues sind alle Namenlosen Objekte (bspw. Temporaries).

Ok, also

string s = "...";
s[0] // <- prvalue

Und ich wäre immer noch daran interessiert, die Ausgabe http://ideone.com/rsHZgs zu verstehen.

[Sone]

Also sind enum-Konstanten lvalues.

Enumeratoren sind keine Objekte.

Wie soll man das verstehen ohne zu wissen, was ein rvalue ist?

Gar nicht. Habe ich das behauptet?

string s;
return s; // <-- s ist kein xvalue

Die Aussage ist natürlich Blödsinn, und kann aus meinen soweit ich sehe nicht abgeleitet werden. s ist ein Objekt mit Namen. Daher ist der Ausdruck mit seinem Namen ein lvalue.

zjraw schrieb:

prvalues sind alle Namenlosen Objekte (bspw. Temporaries).

Ok, also

string s = "...";
s[0] // <- prvalue

Gut, hier bin ich zu pauschal gewesen.
Aber ich habe mich explizit auf lvalue Referenzen als lvalues bezogen. Das beinhaltet Funktionen, die lvalue Referenzen zurückgeben. Reicht das nicht als
Fallunterscheidung?

Und das ist alles noch relativ einfach. Auch wenn ich das zu verallgemeinern versucht habe, ist es an sich wirklich einfach. Da gibt es noch viel schwierigeres.

[otze]

Sone schrieb:

die Begriffe sind doch eigentlich selbst redend.

lvalues: Das sind alle Objekte/Referenzen mit Namen und alle lvalue-Referenzen

Aha. Der Name kommt aber daher, dass l-values links in einer Zuweisung stehen.
Trotzdem kann ich auch einem temporary Dinge zuweisen, wenn ich mag und das Ding einen entsprechend überladenen op= hat. Das macht das temporary aber noch nicht zu einem l-value. Also ist der Name nicht selbstredent.

//edit und welche namentliche Bedeutung pr, gl oder x haben soll...naja.

[Sone]

otze schrieb:

Aha. Der Name kommt aber daher, dass l-values links in einer Zuweisung stehen.
Trotzdem kann ich auch einem temporary Dinge zuweisen, wenn ich mag und das Ding einen entsprechend überladenen op= hat. Das macht das temporary aber noch nicht zu einem l-value. Also ist der Name nicht selbstredent.

Nein, das ist er leider tatsächlich nicht, auf den zweiten Blick.

//edit und welche namentliche Bedeutung pr, gl oder x haben soll...naja.

Das ist doch alles im Standard erklärt!
pure rvalues, generalized lvalues und expiring values. Alles gut gewählt.

[otze]

Sone schrieb:

Das ist doch alles im Standard erklärt!

Und jtzt geh bitte einen Schritt zurück von deinem Monitor, schließe die Augen, überlege dir was du da geschrieben hast, und was mein Kritikpunkt war. Also erklären wir jetzt Dinge mit dem Standard, welcher Begriffe einführt, die so selbstredent sind, dass wir sie wieder im Standard nachschlagen müssen? Überlege dir, ob das ein gute Strategie ist.

Und zu deinem "gut gewält". "pure" ist wohl eines der mehrdeutigsten Begriffe überhaupt, x ist eine der dümmsten Abkürzungsbuchstaben überhaupt (x kann auch einfach als Platzhalter gebraucht werden oder steht im zweifelsfall für so gut wie jedes Wort im Lexikon das mit ex- beginnt. ).

Und du brauchst mir nicht erklären, was die Dinger bedeuten und wie man sie unterscheidet. Das interessiert mich nicht(weil ich es entweder weiß, oder es vom eigentlichn Punkt ablnken würde). Was mich interessiert ist: Es ist ein schlechtes Zeugnis für eine Sprache, wenn neue zentrale Sprachfeatures ohne Benutzung des Standards nicht erklärbar sind. Stell dir einfach mal vor, du arbeitest und ein Kollege fragt dich in der Kaffeepause, wie das nochmal mit den rvalue referenzen war. "Kein Problem, wir sehen gleich im Standard nach, das ist alles ganz einfach"? Eher nicht.

[Sone]

zjraw schrieb:

Und ich wäre immer noch daran interessiert, die Ausgabe http://ideone.com/rsHZgs zu verstehen.

gut, ich gehe das mal Schritt für Schritt durch und versuche mit dem Standard zu erklären, was passiert.

A const& i = hi(A());

Gut. Zuerst wird die Referenz (der Funktionsparameter von hi ) an die Temporary gebunden. Selbstredend. Anschließend wird diese Referenz zurückgegeben. Das ist eine Dangling Reference, ein Klassiker.

A const& i = static_cast<A const&>(A());

Das hier ist interessant. Du hast bereits das Zitat gebracht:

§5.2.9/4 schrieb:

Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t (8.5).
The effect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion.

Das heißt, es wird sozusagen die Referenz erzeugt, es gibt eine Lebenszeitverlängerung, aber diese beschränkt sich auf diese "temporäre Referenz" - und die Zuweisung dieser Referenz zu i ist einfach:

then the reference is bound to the initializer expression lvalue

Das heißt, nach der Zeile ist der Scope der temporären Referenz vorbei, und es gibt kein Objekt mehr. Die Referenz i ist ungültig.

A const& i = std::move(A());

Wie schon früher von mir erklärt, ist das effektiv dasselbe wie dein unterstes Beispiel:

A const& i = static_cast<A&&>(A());

Du weist also i ein xvalue zu. Nach Standard ist das dasselbe wie oben - es wird die temporäre Referenz erzeugt, Lebenszeitverlängerung für die Zeile, und dann:

the reference is bound to the value of the initializer expression

Also für beide Fälle wieder keine Lebenszeitverlängerung.

Das heißt, alle vier Beispiele müssten

CD hi

ausgeben- und der Compiler hat Unrecht. Das wäre fatal, ich kann mir kaum vorstellen das etwas so fundamentales falsch implementiert wird.

Theoretisch. Mit Sicherheit habe ich es falsch interpretiert. Sicher weiß camper es besser. Also, falls jemand Lust hat, mir einzureiben wie wenig ich den Standard verstehe, nur her damit...

[Sone]

Stell dir einfach mal vor, du arbeitest und ein Kollege fragt dich in der Kaffeepause, wie das nochmal mit den rvalue referenzen war. "Kein Problem, wir sehen gleich im Standard nach, das ist alles ganz einfach"? Eher nicht.

Deswegen hat Marc++us (oder wer war das noch) es auch passend erklärt: Man wartet erst einmal, wie sich C++11 in der Praxis bewährt. Deswegen nutzen das viele in Hobby-Projekten und in diversen Code-Schnipseln im Forum, aber keine eurer Firmen nutzt C++11 so konsequent.

Oder? Würde mich wundern.

Es ist ein schlechtes Zeugnis für eine Sprache, wenn neue zentrale Sprachfeatures ohne Benutzung des Standards nicht erklärbar sind.

Deswegen ist C++ ja auch für die Verrückten, zum dritten mal.

Und zu deinem "gut gewält". "pure" ist wohl eines der mehrdeutigsten Begriffe überhaupt, x ist eine der dümmsten Abkürzungsbuchstaben überhaupt (x kann auch einfach als Platzhalter gebraucht werden oder steht im zweifelsfall für so gut wie jedes Wort im Lexikon das mit ex- beginnt. ).

Wie willst du es denn griffig abkürzen, sodass man es oft im Standard verwenden kann? expvalue? Klingt ebenso bescheuert und erinnert an "exponential". exvalue hört sich nach Ex-Partner an, und expiring-value ist zu lang und kein geschlossener Term.

[camper]

ideone hat Unrecht. Übrigens tritt der Fehler erst ab g++ 4.7 auf, mit 4.6 wird es noch richtig gemacht (getested rückwärts bis 3.4.6, dann nat. ohne den rvalue-Teil des Codes). clang 3.3 bringt auch die richtige Reihenfolge.
C++ Standard Core Language Issue #1376
Wer Lust hat, sucht noch den entsprechenden bug-Report bei gcc raus - ich nehme mal an, der existiert schon.

[Sone]

C++ Standard Core Language Issue #1376

Der Fix den sie vorschlagen ist falsch. Die Variable muss temporär sein. Ich sehe auch keine Irritation bei dem Paragraph, so wie ich ihn oben offensichtlich richtig interpretiert habe, ist alles eindeutig. Auch Referenzen können temporär sein.

camper schrieb:

Wer Lust hat, sucht noch den entsprechenden bug-Report bei gcc raus - ich nehme mal an, der existiert schon.

Hier, ist auch für GCC 4.7 gemeldet: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202

[Nathan]

out, wieso tust du uns das an??

[Sone]

Nathan schrieb:

out, wieso tust du uns das an??

Wieso antun? Ich froh, aus diesem Thread habe ich viel gelernt.