lvalue to rvalue-reference conversion

Programmiersprachen, APIs, Bibliotheken, Open Source Engines, Debugging, Quellcode Fehler und alles was mit praktischer Programmierung zu tun hat.
Antworten
dawit
Beiträge: 42
Registriert: 05.02.2011, 17:06

lvalue to rvalue-reference conversion

Beitrag von dawit »

Guten Abend!
Habe ungefähr folgenden Code:

Code: Alles auswählen

struct Base {};
struct Derived : Base {};

std::unique_ptr<Base> func()
{
    std::unique_ptr<Base> base;
    return base; // das geht

    return std::unique_ptr<Derived>{}; // das auch

    std::unique_ptr<Derived> derived;
    return derived; // das nicht: invalid conversion from 'std::unique_ptr<Derived>' to 'std::unique_ptr<Derived>&&'
}
So weit ich das verstanden habe, wird beim zurückgeben einer lokalen Variable der Move-Konstruktor aufgerufen, was bei den ersten zwei Beispielen ja auch sauber funktioniert. Beim dritten halt nicht, wobei da eigentlich wie beim zweiten Beispiel der Konvertierungs-Move-Konstruktor von std::unique_ptr aufgerufen werden müsste, oder?
Benutzeravatar
Schrompf
Moderator
Beiträge: 5045
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas
Wohnort: Dresden
Kontaktdaten:

Re: lvalue to rvalue-reference conversion

Beitrag von Schrompf »

Die direkte Lösung lautet:

Code: Alles auswählen

    std::unique_ptr<Derived> derived;
    return std::move(derived); 
aber das verwundert mich gerade. Eigentlich müsste der Rückgabewert automatisch ein RValue werden.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: lvalue to rvalue-reference conversion

Beitrag von CodingCat »

Schrompf hat geschrieben:aber das verwundert mich gerade. Eigentlich müsste der Rückgabewert automatisch ein RValue werden.
Das implizite Move an dieser Stelle ist im Standard etwas umständlich über die C++03-Kritierien für Copy Elision gelöst. Es ist anzunehmen, dass es dafür gute Gründe gibt, und sei es nur Abwärtskompatibilität.

Die Regelung sieht vor, Kandidaten für Copy Elision in der Overload-Auflösung zunächst wie R-Values zu behandeln, um dann bei Fehlschlag ggf. auf die Behandlung als L-Value zurückzufallen. Die Kriterien für Copy Elision wiederum setzen aber sinnigerweise eine exakte Übereinstimmung der Typen des bei der Rückgabe referenzierten Objekts (std::unique_ptr<Derived>) und des tatsächlich zurückgegebenen Objektes (vom angegebenen Rückgabetyp std::unique_ptr<Base>) voraus, top-level const-volatile-Qualifizier vom Vergleich selbstverständlich ausgenommen. Da diese Übereinstimmung hier nicht gegeben ist, muss der Cast zur R-Value durch move explizit erfolgen.

Warnung: Dies sollte NICHT dazu verleiten, grundsätzliche alle Rückgaben mit explizitem move zu versehen, da dieses das Wegoptimieren der Move-Konstruktion durch Copy Elision per Standard verbietet.
C++14 Draft, Passagen 12.8.31[...]32 hat geschrieben:When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
  • in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
  • [...]
When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If overload resolution fails, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
dawit
Beiträge: 42
Registriert: 05.02.2011, 17:06

Re: lvalue to rvalue-reference conversion

Beitrag von dawit »

Schrompf hat geschrieben:aber das verwundert mich gerade. Eigentlich müsste der Rückgabewert automatisch ein RValue werden.
Genau das dachte ich auch.
CodingCat hat geschrieben:Die Regelung sieht vor, Kandidaten für Copy Elision in der Overload-Auflösung zunächst wie R-Values zu behandeln, um dann bei Fehlschlag ggf. auf die Behandlung als L-Value zurückzufallen.
Die automatische Umwandlung zu rvalues findet also nur statt, wenn Copy Elision möglich ist, und dies geht wiederum nur, wenn Quell - und Zieltyp gleich sind. Ist das so richtig?
Benutzeravatar
dot
Establishment
Beiträge: 1745
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: lvalue to rvalue-reference conversion

Beitrag von dot »

Ich glaub, ich persönlich würd hier statt explizitem std::move() einfach einen static_cast im return bevorzugen, der dann weiterhin copy elision + implizites move erlauben sollte...
dawit
Beiträge: 42
Registriert: 05.02.2011, 17:06

Re: lvalue to rvalue-reference conversion

Beitrag von dawit »

In diesem Fall werde ich einfach direkt ein std::unique_ptr<Base> anlegen. Mir war einfach nicht klar, warum die Konvertierung zu einem rvalue nicht funktionierte.
Danke für die Hilfe!

Viele Grüße
David
Antworten