Motivation et pièges (?) Du mot-clé auto en C ++ 11


20

Je me demandais récemment pourquoi le mot clé a autoété choisi en C ++ 11 pour marquer une variable dont le type doit être déduit par le compilateur, comme dans

auto x = 1;

Puisque

  1. var semble plus courant dans d'autres langages de programmation (par exemple C #, Scala, JavaScript), et
  2. Pour autant que je comprends la nouvelle sémantique de la autorétrocompatibilité des ruptures (elle était rarement utilisée mais avait une signification différente dans les versions précédentes de C ++, voir par exemple ici )

Je voulais demander s'il y avait une raison particulière de choisir auto(en faveur de varou tout autre mot clé). Y a-t-il eu une discussion spécifique sur ce problème avant la publication de la norme C ++ 11?

Existe-t-il également des incompatibilités possibles lors de la recompilation du code C ++ hérité avec un compilateur C ++ 11?


9
La nouvelle sémantique de autopourrait rompre la compatibilité descendante, mais, selon la fréquence d' varutilisation en tant que nom de variable par rapport à la fréquence d'utilisation du automot-clé dans le code antérieur à 11, le comité aurait pu penser qu'il rompt la compatibilité moins dramatiquement que l'introduction d'un nouveau mot-clé serait.
sepp2k

2
"Dans l'état actuel des choses, cette question ne convient pas à notre format de questions et réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise spécifique, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et peut-être rouverte, voir la FAQ pour obtenir des conseils. ": Cette question porte sur un fait: y a-t-il eu une discussion sur ce sujet. Il y a deux réponses possibles: OUI et NON.
Giorgio

2
Bien sûr, il y a eu une discussion, ce qui rend la question un peu inutile à cet égard. La question autovs varest la référence à 90% de votre texte, et cette question n'a pas de résultat définitif. (même si je ne suis pas celui qui a voté pour fermer)
Telastyn

1
@Telastyn: Si j'avais su qu'il y avait eu une discussion sur ce sujet, je ne l'aurais pas demandé. La recherche de "auto versus var C ++" ou "auto C ++" n'a rien donné sur ce sujet.
Giorgio

1
autoa été proposé pour C ++ avant d' varêtre introduit en C # donc la question devrait être de savoir pourquoi C # n'utilise pas auto. var a une signification différente dans JavaScript et Scala
adrianm

Réponses:


37

Presque chaque mot que vous pourriez penser ajouter comme mot-clé à une langue a presque certainement été utilisé comme nom de variable ou autre partie du code de travail. Ce code serait rompu si vous faisiez de ce mot un mot-clé.

La chose incroyablement chanceuse autoest qu'il s'agissait déjà d'un mot-clé, donc les gens n'avaient pas de variables avec ce nom, mais personne ne l'a utilisé, car c'était la valeur par défaut. Pourquoi taper:

auto int i=0;

quand

int i=0;

signifiait exactement la même chose?

Je suppose que quelque part sur la planète, il y avait une petite quantité de code qui utilisait «auto» à l'ancienne. Mais cela pourrait être corrigé en supprimant l '«auto» et cela fonctionnerait à nouveau. C'était donc un choix assez évident de réutiliser le mot-clé.

Je pense aussi que c'est un sens plus clair. Si vous avez travaillé avec des variantes et autres, quand vous voyez, varvous pouvez penser que la déclaration est en quelque sorte moins fortement tapée que si vous avez appuyé vous-même sur toutes les touches du clavier pour spécifier le type de la variable. Pour moi, autoil est plus clair que vous demandez au compilateur de déduire automatiquement le type, qui est tout aussi fort que si vous l'aviez spécifié vous-même. Ce fut donc vraiment une pause très chanceuse qui a mis un bon nom à la disposition du comité.

Pour clarifier la (petite) rupture:

Si tu avais

auto int i=0;

et essayé de compiler avec un compilateur C ++ 11, vous obtiendrez maintenant une erreur telle que

erreur C3530: 'auto' ne peut pas être combiné avec un autre spécificateur de type

C'est trivial, vous supprimez simplement l'auto ou l'int et recompilez.

Il y a cependant un problème plus important. Si tu avais

auto i = 4.3;

C et le très ancien C ++ feraient iun int(comme ce serait le cas si vous vous étiez arrêté auto- la déclaration par défaut était int). Si vous êtes resté très longtemps sans compiler ce code, ou si vous avez utilisé d'anciens compilateurs, vous pourriez avoir une partie de ce code, au moins en théorie. C ++ 11 en ferait un doublepuisque c'est ce que 4.3 est. (Ou peut-être un float, je suis toujours en mode Boxing Day, mais ce n'est pas un an int.) Cela pourrait introduire de subtils bugs dans votre application. Et sans avertissements ni erreurs du compilateur. Les personnes dans ce bateau doivent rechercher globalement pour autos'assurer qu'elles ne l'utilisent pas à l'ancienne avant de passer à un compilateur C ++ 11. Heureusement, un tel code est extrêmement rare.


Merci pour une réponse très claire. +1 Je comprends le compromis entre l'abandon de la compatibilité descendante d'une manière presque inoffensive et le risque fort que l'ancien code ne soit pas rompu par le nouveau mot clé.
Giorgio

Y a-t-il réellement une incompatibilité? Un compilateur C ++ 11 ne va-t-il pas simplement ignorer le autos'il est suivi d'un nom de type?
aaaaaaaaaaaa

1
Visual C ++ 2012 dit error C3530: 'auto' cannot be combined with any other type-specifierà cette ligne
Kate Gregory

3
@KateGregory: En fait, il n'y a pas de problème avec auto i = 4.3;, car c'était mal formé en C ++ 03 / C ++ 98. C ++ n'a pas repris la règle «implicit int» que C89 avait (et a été supprimée dans la révision C99).
Bart van Ingen Schenau

1
@Kate Gregory: Si vous pouviez prendre en compte les observations de Bart et changer votre réponse en conséquence, je la marquerais comme la réponse acceptée.
Giorgio
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.