Kritik eines FAQ-Beitrages


  • Mod

    CStoll schrieb:

    du übergibst eine temporäre Variable an einen Referenzparameter.

    und das ist durchaus NICHT illegal. was der standard verbietet, ist, dass ein rvalue an eine referenz auf non-const gebunden wird. das ist etwas (fast) ganz anderes. jedenfalls wird in diesem falle das ergebnis des =operators (das ein lvalue ist) an den parameter der funktion gebunden. wenn das tatsächlich illegal wäre, solltest du das durch ein entsprechendes zitat des standards untermauern können. die behauptung, man könnte temporaries nicht an referenzen auf nicht-const binden, wird schon durch das gewöhnliche catch mit einer referenz auf nicht-const widerlegt.



  • @camper
    Das der Beitrag keine FAQ ist sehe ich ein. Der stammt ja auch noch aus einer Zeit, in der FAQs häufig auch einfach lebendige/interessante/relevante Diskussionen zwischen mehreren Leuten waren, wo am Ende irgendwelche Groschen gefallen sind. Mittlerweile sind wir mehr zum "ich-erklär-euch-mal-was"-Stil übergegangen (wobei mit "ich" nicht ich gemeint bin sondern der jeweeils erklärende) und unter diesem Gesichtspunkt würde ich den genannten Beitrag schlicht löschen.

    Deine Kritikpunkte kann ich ehrlich gesagt nicht nachvollziehen. Beide Aussagen finde ich als Daumenregeln (und als solche sind sie gedacht) nach wie vor sinnvoll. Das man Gegenbeispiele konstruieren kann, hat imo keinen Einfluss auf die Bedeutung der Daumenregeln. Wichtig ist, dass die Mehrzahl der Fälle gut behandelt wird: und einen Parameter den man als const-Ref erhalten hat als const-Ref zurückzugeben ist im Allgemeinen einfach nicht sinnvoll und gefährlich.

    Btw: Marshal Cline et al. haben in ihrem Buch "C++ FAQs" folgenden Eintrag:
    FAQ 32.08
    Q:

    Should a parameter passed by const reference be returned by const reference?

    A:

    No; it might create a dangling reference, which could destroy the world.
    [...]
    Note that if a function accepts a parameter by non-const reference[...], returning a copy of this reference paramater is safe because a temporary cannot be passed by non-const reference.

    Merkregeln, die für die wahrscheinlich bekannteste C++ FAQ der Welt ok sind, sollten imo auch für dieses Forum ok sein.

    @CStoll
    campers Beispiel 1) ist durchaus gültiges C++. Das ist der Punkt mit dem "blows your whole leg off." Wenn man sich in C++ etwas anstrengt, fliegen die Beine nur so durch die Gegend 😉


  • Mod

    ich habe ja gar nichts gegen die regeln. nur gegen die argumentation, die zu diesen regeln führt, halte ich für nicht ganz stichhaltig und wollte das mal erwähnt haben. und auch auch renomierte authoren können sich mal irren. der standard selbst hat ja ein paar 100 defekte - und darüber haben sich viele kluge leute lange den kopf zerbrochen. das beispiel mit der zuweisung war noch sehr deutlich. ein weitaus weniger offensichtlich esoterisches beispiel entstünde, falls wir das "name-constructor" idiom einsetzen (wenn ich mich nicht irre, wird das in dieser faq auch mal erwähnt). a la

    struct X
    {
        X() {}
        int a_, b_, c_;
        X& set_a(int a) { a_ = a; return *this; }
        X& set_b(int b) { b_ = b; return *this; }
        X& set_c(int c) { c_ = c; return *this; }
    };
    X& foo(X&);
    int main()
    {
       X& x = foo( X().set_a( 0 ).set_b( 1 ).set_c( 2 ) );
    // benutze x - ups
    ]
    

    hier bauen wir unser X ganz so wie es gedacht ist. und trotzdem ist das ergebnis eine katastrophe 🙂



  • Hi camper,
    was schlägst du also konkret vor? Möchtest du den FAQ-Eintrag um einen Beitrag ergänzen? Willst du den vorhandenen Eintrag editieren? Soll ich den gesamten Eintrag löschen?


  • Mod

    das überlass ich dir. eine entsprechende ergänzung richtet sicher keinen schaden an.



  • Hallo,
    mir scheinen zwei Wege sinnvoll:
    a) du schreibst eine Ergänzung zu dem vorhandenen Beitrag.
    b) ich lösche den alten Thread und du schreibst einen neuen Beitrag, der das Thema erklärt.

    a) kann man wohl auf zwei Arten realisieren. Entweder lässt du mir deine Ergänzung zukommen und ich füge sie dann an (Nachteil: Das Posting läuft dann unter meinem Namen) oder ich verschiebe den Beitrag hier her, du ergänzt und ich verschiebe zurück.


  • Mod

    oder du ergänzt den beitrag schlicht mit einem zitat



  • camper schrieb:

    oder du ergänzt den beitrag schlicht mit einem zitat

    Ok, das übersteigt so erstmal mein Verständnis (setzt wohl einen IQ > 20 voraus). Kannst du das nochmal etwas genauer erklären?

    Wo muss ich was anklicken? Was soll ich wie zitieren?


  • Mod

    du kannst doch in diesem thread zitieren. anstatt das dann aber hier zu posten, übeträgst du das zitat dann per c&p schlicht in den anderen thread.



  • @camper: Nachdem ich seit gestern versuche, dahinterzukommen, worum es geht wäre es mir sehr lieb wenn du etwas deiner Zeit opfern würdest, und dieses Thema in einem neuen Thread für die FAQ nochmals aufrollen könntest.

    HumeSikkins schrieb:

    Ok, das übersteigt so erstmal mein Verständnis (setzt wohl einen IQ > 20 voraus). Kannst du das nochmal etwas genauer erklären?
    Wo muss ich was anklicken? Was soll ich wie zitieren?

    *lol*

    Greetz, Swordfish


  • Mod

    std::string& s = foo( std::string() = "test" );
    

    das können wir etwas anders schreiben:

    std::string& s = foo( std::string().operator=("test") );
    

    operator= hat diese signatur:

    std::string& std::string::operator=(const char*)
    

    der wesentlich grund, warum das alles so geht ist der, dass der objektparameter einer memberfunktion auch ein rvalue sein darf. innerhalb derfunktion ist *this aber ein lvalue (und was dann anschließend damit passiert unterliegt keinen besonderen beschränkungen, insebondere kann es für den funktionswert benutzt werden). dabei wird aber kein (weiteres) temporary erzeugt. in gewisser weise erkennt man hier, dass das klassenkonzept erst nachträglich in die sprache aufgenommen wurde, es kollidiert in einigen punkten mit dem relativ simplen konzept von l- und rvalues. rvalues von klassenobjekten sind ja auch die einzigen rvalues, die cv-qualifiziert sein können - eben genau deshalb, weil man auf umwegen daraus wieder lvalues erhalten kann. denn const und volatile sind ja letztlich eigenschaften, die nur lvalues sinnvoll zukommen können.



  • Hallo camper,

    schreibst du hier noch was, oder soll ich deine vorigen Beiträge so wie sie sind in den FAQ-Thread reinzitieren?


  • Mod

    HumeSikkins schrieb:

    Hallo camper,

    schreibst du hier noch was, oder soll ich deine vorigen Beiträge so wie sie sind in den FAQ-Thread reinzitieren?

    ich hab nichts mehr hinzuzufügen. zitier mal los 🙂



  • Done. Falls noch was wichtiges fehlt, einfach bescheid sagen.


Anmelden zum Antworten