Gegeben die folgenden Konvertierungsoperatoren
%Vor%Ich würde erwarten, dass die folgenden Konvertierungen alle gültig sind, aber einige geben Kompilierungsfehler ( Live-Beispiel ):
%Vor%Insbesondere scheint 1 identisch mit 3 zu sein und fast identisch mit 2 (ähnlich für 7 bis 9, 8), verhält sich jedoch anders.
Jede Erklärung oder Umgehung?
Meine Motivation ist Noch ein 'Any' , bei dem ich schließlich alle Konvertierungsoperatoren explicit machen musste. Um Probleme mit Typeigenschaften wie std::is_constructible , std::is_convertible zu vermeiden, stieß ich auf neue Probleme.
BEARBEITEN Entschuldigung, bitte ignorieren Sie 3 und 9, mein Fehler (danke Kerrek SB). Dennoch bleiben 7 und 8 Probleme. Auch scheint explicit irrelevant zu sein, sorry nochmal.
BEARBEITEN 2 Gerade bemerkt, dass
%Vor% sind gültig, wenn die Konvertierungsoperatoren nicht explicit sind. Das ist also der Punkt, an dem explicit ankommt: Anfangs verwendeten meine Beispiele die Kopierinitialisierung, und als ich zu explicit wechselte, musste ich die Direkt-Initialisierung verwenden. Dann ist dieses Problem aufgetreten (Fälle 7 und 8).
%Vor%Aber 7 und 8 bleiben als Probleme
Die zwei Fälle sind die gleichen: direkte Initialisierung mit Rvalue-Argument des Typs A.
Die Kandidatenfunktionen für die direkte Initialisierung sind alle Konstruktoren, und in diesem Fall sind sowohl der Kopierkonstruktor B::B(const B&) als auch der Verschiebekonstruktor B(B&&) brauchbar, da es eine implizite Konvertierung von rvalue A in sowohl const B& als auch in% gibt. Code%. Die Überladungsauflösung kann nicht zwischen diesen beiden Konstruktoren entscheiden, da das Aufrufen einer der beiden eine benutzerdefinierte Konvertierung direkt in den Parametertyp erfordert und benutzerdefinierte Konvertierungssequenzen nur nach der zweiten Standardkonvertierung geordnet sind:
B&&: Benutzerdefinierte Konvertierungssequenz U1 ist eine bessere Konvertierungssequenz als eine andere benutzerdefinierte Konvertierungssequenz U2, wenn sie dieselbe benutzerdefinierte Konvertierungsfunktion enthält ... und die zweite Standardkonvertierungssequenz von U1 ist besser als die zweite Standardkonvertierungssequenz von U2. "
Dies unterscheidet sich vom Aufruf einer Member-Funktion, die sowohl & amp; & amp; und const & amp; -qualifizierte Überladungen, weil in diesem Fall die Überladungsauflösung die Referenzbindungen von rvalue-Argument zu impliziertem Objektparameter nach
rangiertDie Standardkonvertierungssequenz S1 ist eine bessere Konvertierungssequenz als die Standardkonvertierungssequenz S2, wenn S1 und S2 Bezugsbindungen (8.5.3) sind und keiner von beiden verweist auf einen impliziten Objektparameter einer nicht statischen Mitgliedsfunktion, die ohne ref-Qualifikationsmerkmal deklariert wurde , und S1 bindet eine rvalue-Referenz an einen rvalue und S2 bindet eine lvalue-Referenz.
Tags und Links c++ c++11 rvalue-reference ref-qualifier conversion-operator