Wenn T ein Klassentyp mit der Standardunterschrift für den Zuweisungsoperator ist, können wir schreiben:
erzeugt eine hängende Referenz. Allerdings mit der Unterschrift:
%Vor%Der obige Code mit Dangling-Referenz kann nicht kompiliert werden. Dies würde einige Situationen verhindern, in denen wir einen Lvalue zurückgeben, der ein temporäres Objekt kennzeichnet - unerwünschte Situationen, weil sie zu dangelnden Referenzen führen können.
Gibt es einen Grund, dies nicht zu tun? würden wir irgendwelche gültigen Anwendungsfälle für die Zuweisungsoperatoren deaktivieren?
Ich denke, die gleichen Kommentare können auch für die zusammengesetzten Zuweisungsoperatoren gelten, += usw. Ein realistischerer Fall könnte sein:
wo der Tippfehler bis zur Laufzeit UB unbemerkt bleiben würde.
Nach meiner Erfahrung in dem seltenen Fall, dass Sie einem rvalue zuweisen möchten, schreiben Sie
%Vor% und macht as_lvalue( tmp() ) = foo statt tmp()=foo ist keine große Barriere. Es bedeutet, dass das gelegentliche bisschen Code, das einem rvalue zugewiesen hat, jetzt bricht; Ich persönlich würde vermuten, dass die meisten dieser Fälle tatsächlich nicht gefundene Fehler sind.
Die Beschränkung jedes Typs in std auf lvalue-restricted auf operator= wurde während der C ++ 11 Standardisierung in Frankfurt (2009/07) berücksichtigt. Die in den Protokolle aufgezeichnete Lösungsansätze waren:
N2819, "N2819 Ref-Qualifier für Zuweisungsoperatoren des Standards Bibliothek " wurde ursprünglich vom LWG geprüft. Dieser Vorschlag versuchte, 350 Kopierzuweisungsoperatoren in der C ++ - Standardbibliothek zu ändern, um Zuweisungsoperationen zu verhindern, bei denen der linke Operand ein rvalue ist. Aufgrund der großen Anzahl der erforderlichen Änderungen wurde der Vorschlag an die EWG gesendet mit der Bitte, das Standardverhalten für implizite Kopierzuweisungsoperatoren neu zu überdenken, so dass die Zuordnung zu einem rvalue nicht erlaubt ist. Die EWG hat aus Gründen der Abwärtskompatibilität beschlossen, den Status quo beizubehalten.
Ich lese das als "350 Änderungen? Wie wäre es mit einer Sprachveränderung?". EWG sagte "nein, diese Sprachveränderung könnte die Kompatibilität zerstören". Und möglicherweise ist der Vorschlag am Rebstock gestorben.
Im Jahr 2009 war C ++ 11 (damals C ++ 0x) bereits hinter dem Zeitplan zurück. Der Vorschlag beinhaltete 300 Änderungen an der Bibliothek, die (theoretisch) zu Regressionen führen könnten. Kein anderer Grund wurde in den Protokollen zitiert. Es ist verständlich, dass es abgelehnt wird, den Schmerz der Regressionen nicht wert zu sein (oder sogar die Häufigkeit von Regressionen zu prüfen!). Ich würde also keine Vorurteile auf die Idee nehmen, nur weil C ++ sie in std abgelehnt hat.
Tags und Links c++ c++11 operator-overloading assignment-operator