Ich erinnere mich, dass jemand mir das einmal gesagt hat,
"% code_% muss nicht innerhalb von bereichsbasierten for-Schleifen verwendet werden nicht in der Sprache mehrdeutig sein, wenn wir es entfernen würden. "
Ist das eine wahre Aussage? Ist der folgende Code gültige C ++ - Syntax?
%Vor% Ich hatte angenommen, dass dies bereits gültige Syntax war, aber als ich zum kompilieren mit
auto
ging, wurde der folgende Fehler angezeigt:
Der Compiler erkennt dies immer noch als eine bereichsbasierte for-Schleife, warum kann er nicht auch den Typ ableiten?
Das:
%Vor%Syntax ist derzeit nicht gültig, aber es gab einen Vorschlag, diese gültige Syntax zu erstellen, und die Syntax wird in gcc 5.2 ( ) unterstützt sieh es live ):
%Vor%und wenn wir das im C ++ 14 Modus versuchen, heißt es:
Warnung: bereichsbasierte for-Schleife ohne Typspezifizierer nur verfügbar mit -std = c ++ 1z oder -std = gnu ++ 1z
Das würde also klar funktionieren und wurde in gcc implementiert. Es sieht so aus, als ob diese Funktion in gcc 6.0 entfernt wurde.
Soweit ich das beurteilen kann, wurde dies in gcc implementiert mit der Erwartung, dass Vorschlag N3853: Range-Based For-Loops: Die nächste Generation würde akzeptiert, aber abgelehnt und die aktualisierte Version N3994 sagt:
Dies aktualisiert N3853 (siehe [1]), das die Syntax "für (elem: Bereich ", durch Hinzufügen von Unterstützung für Attribute und Beantworten zusätzlicher Fragen. Bitte beachten Sie den ursprünglichen Vorschlag für die Begründung dahinter Diese Funktion wird hier nicht wiederholt.
Wir können sehen, dass es aus der EWG-Ausgabe 81 abgelehnt wurde und wir können dies auch aus dem Urbana-Sitzungsprotokoll
Die Syntax erfordert einen Typ für eine Anweisung "range-for", auch wenn es auto
ist. for (elem : range) {...}
ist ein Syntaxfehler, also technisch, ja, es stimmt, die Sprache könnte angeben, dass dies for (auto elem : range) {...}
entspricht.
Es gibt jedoch mindestens zwei Hauptprobleme:
Der erste ist, dass for (T elem : range)
nicht T
benötigt, um auto
zu verwenden. Wenn der Compiler for (elem
sieht, hat er noch keine Möglichkeit zu wissen, ob elem
eine typedef
von einem äußeren Bereich oder eine neu deklarierte Variable ist. Es ist nicht mehrdeutig, aber für Compiler ist es etwas kompliziert, es richtig zu handhaben.
Das zweite ist, dass Sie dann die Frage bekommen, was der Standard sein sollte. Legitime Argumente könnten für auto
gemacht werden. Legitime Argumente könnten für auto &
gemacht werden. Legitime Argumente könnten für const auto &
gemacht werden. Der aktuelle Ansatz lässt nur den Programmierer wählen. Legitime Argumente könnten wahrscheinlich (ich bin mir nicht ganz sicher) auch für einige von denen mit auto
durch decltype(auto)
ersetzt werden.