Ich habe Compiler, die sich über ein kleines C ++ 14-Code-Snippet nicht einig sind:
%Vor%Das Programm wird von g ++ 4.9.3, g ++ - 5.1.0, g ++ - 5.2.0 und VisualStudio 2015 akzeptiert, aber nicht von clang ++ - 3.7.
clang ++ - 3.7 leitet den Rückgabetyp zu unmovable (Wert) und nicht unmovable& ab.
Wenn das Programm leicht geändert wird, so dass die Variable u global ist, dann stimmen alle Compiler auf den Fehler zu.
Wie ich es verstehe, sollte das eingefangene u im Lambda vom Typ unmovable& sein, wenn die Variable lokal ist.
Ich habe nicht den C ++ 14 Standard, aber hoffentlich ist der Entwurf von github relevant. Meine Interpretation von 7.1.6.2 und 7.1.6.4 ist, dass decltype(auto) wird decltype(u) aus der Rückkehr, die im globalen Fall sollte unmovable (Wert) und in der Lambda-Referenz erfassen der lokalen u , es sollte unmovable& werden, da die erfasste Variable vom Typ unmovable& sein muss. Dies würde bedeuten, dass clang ++ es falsch verstanden hat.
Wenn ich das Lambda und seine Verwendung etwas ändere:
%Vor% Dann akzeptieren alle Compiler es, unabhängig davon, ob u global oder lokal ist, was meiner Meinung nach meine Interpretation des decltype(auto) -Abzugs verstärkt, da v hier eindeutig vom Typ unmovable& wird.
Ist meine Interpretation korrekt und daher klingt ++ falsch?
kling scheint mir richtig. Ich stimme Ihrer Interpretation zu, dass der Lambda-Rückgabetyp decltype(u) sein muss, aber nicht dass decltype(u) ist unmovable& .
5.1.2 Lambda-Ausdrücke [expr.prim.lambda]
18 Jeder ID-Ausdruck innerhalb der zusammengesetzten Anweisung eines Lambda-Ausdrucks , der eine odr-Verwendung (3.2) von einem ist Die durch die Kopie erfasste Entität wird in einen Zugriff auf das entsprechende unbenannte Datenelement der Datei transformiert Verschlusstyp [ Hinweis: Ein ID-Ausdruck , der keine odr-Verwendung ist, bezieht sich auf die ursprüngliche Entität, niemals auf ein Mitglied des Schließungstyps. Darüber hinaus verursacht ein solcher id-Ausdruck keine implizite Erfassung der Entität. - Endnote ] [...]
19 Jedes Auftreten von
decltype((x))wo [...]
p19 trifft nicht zu, da Sie decltype(u) , nicht decltype((u)) .
p18 sagt dann, dass das u in decltype(u) keine odr-use ist, es bezieht sich auf die ursprüngliche Entität, es wird nicht in einen Zugriff des Members des Schließungstyps umgewandelt.
Allerdings macht p19 es klar, wenn Sie Ihre return -Anweisung als
dann gibt das Lambda u als Referenz zurück. Dies funktioniert mit clang, wenn dies das gewünschte Verhalten ist.