Motivation und Fallstricke (?) Des Schlüsselworts auto in C ++ 11


20

Ich habe mich kürzlich gefragt, warum das Schlüsselwort autoin C ++ 11 gewählt wurde, um eine Variable zu markieren, deren Typ vom Compiler abgeleitet werden muss, wie in

auto x = 1;

Schon seit

  1. var scheint häufiger in anderen Programmiersprachen (z. B. C #, Scala, JavaScript) und
  2. Soweit ich die neue Semantik verstehen autobricht Abwärtskompatibilität (es selten benutzt wurde , aber eine andere Bedeutung in früheren Versionen von C ++ hatte, siehe zB hier )

Ich wollte fragen, ob es einen besonderen Grund für die Wahl gibt auto(zugunsten eines varoder eines anderen Schlüsselworts). Gab es eine spezielle Diskussion zu diesem Problem, bevor der C ++ 11-Standard veröffentlicht wurde?

Gibt es auch mögliche Inkompatibilitäten, auf die wir achten sollten, wenn wir älteren C ++ - Code mit einem C ++ 11-Compiler neu kompilieren?


9
Die neue Semantik von autokönnte die Abwärtskompatibilität beeinträchtigen, aber je nachdem, wie oft varein Variablenname verwendet wird, verglichen mit der autoHäufigkeit, mit der das Schlüsselwort in Code vor 11 verwendet wird, hat das Komitee möglicherweise die Ansicht vertreten, dass die Kompatibilität weniger dramatisch beeinträchtigt wird als die Einführung eines neuen Stichwort würde.
sepp2k

2
"Gegenwärtig passt diese Frage nicht zu unserem Q & A-Format. Wir erwarten, dass die Antworten durch Fakten, Referenzen oder spezifisches Fachwissen gestützt werden, aber diese Frage wird wahrscheinlich Debatten, Argumente, Abstimmungen oder erweiterte Diskussionen hervorrufen. Wenn Wenn Sie der Meinung sind, dass diese Frage verbessert und möglicherweise erneut geöffnet werden kann, lesen Sie die häufig gestellten Fragen (FAQ). Es gibt zwei mögliche Antworten: JA und NEIN.
Giorgio

2
Natürlich gab es eine Diskussion, die die Frage in dieser Hinsicht irgendwie sinnlos macht. Die autovs- varFrage ist, worauf sich 90% Ihres Textes bezieht, und diese Frage hat kein endgültiges Ergebnis. (obwohl ich nicht derjenige bin, der abgestimmt hat, um zu schließen)
Telastyn

1
@Telastyn: Wenn ich gewusst hätte, dass es eine Diskussion zu diesem Thema gegeben hätte, hätte ich nicht gefragt. Das Googeln nach "auto versus var C ++" oder "auto C ++" ergab zu diesem Thema nichts.
Giorgio,

1
autowurde für C ++ vorgeschlagen, bevor vares in C # eingeführt wurde. Daher sollte die Frage lauten, warum C # nicht auto verwendet. var hat eine andere Bedeutung in JavaScript und Scala
adrianm

Antworten:


37

Fast jedes Wort, das Sie einer Sprache als Schlüsselwort hinzufügen möchten, wurde mit ziemlicher Sicherheit als Variablenname oder als anderer Teil des Arbeitscodes verwendet. Dieser Code würde beschädigt, wenn Sie dieses Wort zu einem Schlüsselwort machen würden.

Das unglaublich Glückliche daran auto ist, dass es sich bereits um ein Schlüsselwort handelte. Die Leute hatten also keine Variablen mit diesem Namen, aber niemand hat es verwendet, weil es die Standardeinstellung war. Warum tippen:

auto int i=0;

wann

int i=0;

genau dasselbe gemeint?

Ich nehme an, irgendwo auf dem Planeten gab es eine kleine Menge Code, der auf die alte Weise "auto" verwendete. Aber es könnte behoben werden, indem das 'Auto' entfernt wird und es würde wieder funktionieren. Daher lag es auf der Hand, das Keyword erneut zu verwenden.

Ich denke auch, dass es eine klarere Bedeutung hat. Wenn Sie mit Varianten und dergleichen gearbeitet haben, vardenken Sie möglicherweise, dass die Deklaration weniger stark getippt ist, als wenn Sie alle Tasten auf der Tastatur selbst gedrückt haben, um den Variablentyp anzugeben. Für mich autowird klarer, dass Sie den Compiler auffordern, den Typ automatisch abzuleiten. Dieser Typ ist genauso stark, als hätten Sie ihn selbst angegeben. Es war also wirklich eine sehr glückliche Pause, die dem Komitee einen guten Namen gegeben hat.

Um den (kleinen) Bruch zu klären:

Wenn du hättest

auto int i=0;

Wenn Sie versucht haben, mit einem C ++ 11-Compiler zu kompilieren, erhalten Sie jetzt eine Fehlermeldung wie

Fehler C3530: 'auto' kann nicht mit einem anderen Typbezeichner kombiniert werden

Dies ist trivial, Sie entfernen nur entweder das Auto oder das Int und kompilieren neu.

Es gibt jedoch ein größeres Problem. Wenn du hättest

auto i = 4.3;

C und das wirklich alte C ++ würden iein int(wie es wäre, wenn Sie aufhören würden auto- Standarddeklaration war int). Wenn Sie lange nicht mit dem Kompilieren dieses Codes gearbeitet haben oder alte Compiler verwendet haben, können Sie zumindest theoretisch einen Teil dieses Codes haben. C ++ 11 würde es zu einem machen, doubleda 4.3 genau das ist. (Oder vielleicht a float, ich bin immer noch im Boxing Day-Modus, aber der springende Punkt ist, kein int.) Dies könnte subtile Fehler in Ihrer gesamten App hervorrufen. Und ohne irgendwelche Warnungen oder Fehler vom Compiler. Die Leute in diesem Boot sollten global suchen auto, um sicherzustellen, dass sie es nicht auf die alte Art und Weise verwendeten, bevor sie zu einem C ++ 11-Compiler wechseln. Glücklicherweise ist ein solcher Code äußerst selten.


Vielen Dank für eine sehr klare Antwort. +1 Ich verstehe den Kompromiss zwischen dem weitgehend harmlosen Löschen der Abwärtskompatibilität und der großen Wahrscheinlichkeit, dass der alte Code nicht durch das neue Schlüsselwort beschädigt wird.
Giorgio

Gibt es überhaupt eine Inkompatibilität? Wird ein C ++ 11-Compiler das nicht einfach ignorieren, autowenn ihm ein Typname folgt?
aaaaaaaaaaa

1
Visual C ++ 2012 sagt error C3530: 'auto' cannot be combined with any other type-specifierzu dieser Zeile
Kate Gregory

3
@KateGregory: Eigentlich gibt es damit kein Problem auto i = 4.3;, weil das in C ++ 03 / C ++ 98 schlecht geformt war. C ++ hat nicht tragen über die ‚impliziten int‘ Regel , dass C89 hatte (und in der C99 Revision fallen gelassen).
Bart van Ingen Schenau

1
@Kate Gregory: Wenn Sie die Beobachtungen von Bart berücksichtigen und Ihre Antwort entsprechend ändern könnten, würde ich sie als akzeptierte Antwort markieren.
Giorgio
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.