Combien coûte trop avec le mot clé automatique C ++ 11?

J'ai utilisé le nouveau automot clé disponible dans la norme C ++ 11 pour les types de modèles compliqués, ce pour quoi je pense qu'il a été conçu. Mais je l'utilise aussi pour des choses comme:

auto foo = std::make_shared<Foo>();

Et plus sceptiquement pour:

auto foo = bla(); // where bla() return a shared_ptr<Foo>

Je n'ai pas vu beaucoup de discussions sur ce sujet. Il semble que cela autopourrait être surutilisé, car un type est souvent une forme de documentation et de vérification de l'intégrité. Où tracez-vous la ligne d'utilisation autoet quels sont les cas d'utilisation recommandés pour cette nouvelle fonctionnalité?

Pour clarifier: je ne demande pas d'avis philosophique; Je demande l'utilisation prévue de ce mot-clé par le comité standard, éventuellement avec des commentaires sur la façon dont cette utilisation prévue est réalisée dans la pratique.

Note latérale: Cette question a été déplacée vers SE.Programmers, puis de nouveau vers Stack Overflow. Une discussion à ce sujet peut être trouvée dans cette méta-question .

Je pense que l'on devrait utiliser le automot - clé chaque fois qu'il est difficile de dire comment écrire le type à première vue, mais le type du côté droit d'une expression est évident. Par exemple, en utilisant:

my_multi_type::nth_index<2>::type::key_type::composite_key_type::
    key_extractor_tuple::tail_type::head_type::result_type

pour obtenir le type de clé composite boost::multi_index, même si vous savez qu'il l'est int. Vous ne pouvez pas simplement écrire intcar cela pourrait être changé à l'avenir. J'écrirais autodans ce cas.

Donc, si le automot clé améliore la lisibilité dans un cas particulier, utilisez-le. Vous pouvez écrire autoquand il est évident pour le lecteur quel type autoreprésente.

Voici quelques exemples:

auto foo = std::make_shared<Foo>();   // obvious
auto foo = bla();                     // unclear. don't know which type `foo` has

const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
                                      // since max_size is unsigned

std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
                                      // ok, since I know that `it` has an iterator type
                                      // (don't really care which one in this context)

Utilisez-le autopartout où vous le pouvez, en particulier const autopour que les effets secondaires soient moins préoccupants. Vous n'aurez pas à vous soucier des types, sauf dans les cas évidents, mais ils seront toujours vérifiés statiquement pour vous, et vous pouvez éviter certaines répétitions. Lorsque cela auton'est pas possible, vous pouvez utiliser decltypepour exprimer des types sémantiquement sous forme de contrats basés sur des expressions. Votre code sera différent, mais ce sera un changement positif.

Facile. Utilisez-le lorsque vous ne vous souciez pas du type. Par exemple

for (const auto & i : some_container) {
   ...

Tout ce qui m'importe ici, c'est ce qu'il iy a dans le conteneur.

C'est un peu comme les typedefs.

typedef float Height;
typedef double Weight;
//....
Height h;
Weight w;

Ici, je ne me soucie pas de savoir si het wsont des flotteurs ou des doubles, seulement qu'ils sont de tout type approprié pour exprimer les hauteurs et les poids .

Ou pensez

for (auto i = some_container .begin (); ...

Ici, tout ce qui m'importe, c'est que c'est un itérateur approprié, supportant operator++(), c'est un peu comme taper du canard à cet égard.

De plus, le type de lambdas ne peut pas être orthographié, tout auto f = []...comme le bon style. L'alternative est de lancer std::functionmais cela vient avec des frais généraux.

Je ne peux pas vraiment concevoir un "abus" de auto. Le plus proche que je peux imaginer est de vous priver d'une conversion explicite en un type significatif - mais vous ne l'utiliseriez pas autopour cela, vous construiriez un objet du type souhaité.

Si vous pouvez supprimer une certaine redondance dans votre code sans introduire d'effets secondaires, cela doit être bon de le faire.

Contre-exemples (empruntés aux réponses de quelqu'un d'autre):

auto i = SomeClass();
for (auto x = make_unsigned (y); ...)

Ici, nous nous soucions du type, nous devons donc écrire Someclass i;etfor(unsigned x = y;...

Fonce. Utilisez-le autopartout où il facilite l'écriture de code.

Chaque nouvelle fonctionnalité dans n'importe quelle langue va être surutilisée par au moins certains types de programmeurs. Ce n'est que par une surutilisation modérée par certains programmeurs expérimentés (et non par des noobs) que le reste des programmeurs expérimentés apprend les limites d'une bonne utilisation. Une surutilisation extrême est généralement mauvaise, mais pourrait être bonne car une telle surutilisation peut conduire à des améliorations de la fonctionnalité ou à une meilleure fonctionnalité pour la remplacer.

Mais si je travaillais sur du code avec plus de quelques lignes comme

auto foo = bla();

où le type est indiqué zéro fois, je pourrais vouloir changer ces lignes pour inclure des types. Le premier exemple est excellent car le type est indiqué une fois, et autonous évite d'avoir à écrire deux fois des types malpropres. Hourra pour C ++++. Mais montrer explicitement le type zéro fois, s'il n'est pas facilement visible dans une ligne proche, me rend nerveux, au moins en C ++ et ses successeurs immédiats. Pour d'autres langages conçus pour fonctionner à un niveau supérieur avec plus d'abstraction, de polymorphisme et de généricité, c'est bien.

Au C ++ et au-delà de 2012 dans le panel Ask Us Anything , il y a eu un échange fantastique entre Andrei Alexandrescu, Scott Meyers et Herb Sutter pour savoir quand utiliser et ne pas utiliserauto . Passez à la minute 25:03 pour une discussion de 4 minutes. Les trois haut-parleurs donnent d'excellents points qui doivent être gardés à l'esprit pour savoir quand ne pas les utiliser auto.

J'encourage fortement les gens à arriver à leur propre conclusion, mais mon emport était de l' utiliser autopartout sauf si :

1. Cela nuit à la lisibilité
2. On s'inquiète de la conversion automatique de type (par exemple à partir de constructeurs, d'affectation, de types intermédiaires de modèle, de conversion implicite entre des largeurs entières)

L'utilisation libérale des explicitaides réduit la préoccupation pour ces derniers, ce qui contribue à minimiser la durée pendant laquelle les premiers sont un problème.

En reformulant ce que Herb a dit, "si vous ne faites pas X, Y et Z, utilisez auto. Apprenez ce que sont X, Y et Z et allez-y et utilisez autopartout ailleurs."

Oui, il peut être abusé au détriment de la lisibilité. Je suggère de l'utiliser dans des contextes où les types exacts sont longs, ou inexprimables, ou non importants pour la lisibilité, et les variables sont de courte durée. Par exemple, le type d'itérateur est généralement long et n'est pas important, donc autofonctionnerait:

   for(auto i = container.begin(); i != container.end(); ++i);

auto ici ne nuit pas à la lisibilité.

Un autre exemple est le type de règle d'analyseur, qui peut être long et alambiqué. Comparer:

   auto spaces = space & space & space;

avec

r_and_t<r_and_t<r_char_t<char>&, r_char_t<char>&>, r_char_t<char>&> spaces = 
   space & space & space;

D'un autre côté, lorsque le type est connu et simple, c'est beaucoup mieux s'il indique explicitement:

int i = foo();

plutôt que

auto i = foo();

auto peut être très dangereux en combinaison avec des modèles d'expression qui sont beaucoup utilisés par les bibliothèques d'algèbre linéaire telles que Eigen ou OpenCV.

auto A = Matrix(...);
auto B = Matrix(...);
auto C = A * B; // C is not a matrix. It is a matrix EXPRESSION.
cout << C; // The expression is evaluated and gives the expected result.
... // <code modifying A or B>
cout << C; // The expression is evaluated AGAIN and gives a DIFFERENT result.

Les bugs causés par ce type d'erreurs sont une difficulté majeure à déboguer. Un remède possible consiste à convertir explicitement le résultat dans le type attendu si vous êtes déterminé à utiliser auto pour le style de déclaration de gauche à droite.

auto C = Matrix(A * B); // The expression is now evaluated immediately.

J'utilise autosans restriction et je n'ai rencontré aucun problème. Je finis même parfois par l'utiliser pour des types simples comme int. Cela fait de c ++ un langage de niveau supérieur pour moi et permet de déclarer des variables en c ++ comme en python. Après avoir écrit du code python, j'écris même parfois par exemple

auto i = MyClass();

au lieu de

MyClass i;

C'est un cas où je dirais que c'est un abus du automot - clé.

Souvent, cela ne me dérange pas quel est le type exact de l'objet, je suis plus intéressé par sa fonctionnalité, et comme les noms de fonction disent généralement quelque chose sur les objets qu'ils retournent, autocela ne fait pas de mal: par exemple auto s = mycollection.size(), je peux deviner que ce ssera une sorte d'entier, et dans les rares cas où je me soucie du type exact, vérifions ensuite le prototype de la fonction (je veux dire, je préfère avoir à vérifier quand j'ai besoin des informations, plutôt qu'à priori lorsque le code est écrit, juste au cas où cela serait utile un jour, comme dans int_type s = mycollection.size()).

Concernant cet exemple de la réponse acceptée:

for ( auto x = max_size; x > 0; --x )

Dans mon code, j'utilise toujours autodans ce cas, et si je veux xêtre non signé, alors j'utilise une fonction utilitaire, nommée say make_unsigned, qui exprime clairement mes préoccupations:

for ( auto x = make_unsigned(max_size); x > 0; --x )

mentions légales: je viens de décrire mon utilisation, je ne suis pas compétent pour donner des conseils!

L'un des problèmes majeurs du programme C ++ est qu'il vous permet d'utiliser la variable non initialisée . Cela nous amène à un comportement de programme non déterministe désagréable. Il convient de noter que le compilateur moderne lance désormais des messages d'avertissement / message appropriés si le programme se lasse de l'utiliser.

Juste pour illustrer cela, considérez le programme c ++ ci-dessous:

int main() {
    int x;
    int y = 0;
    y += x;
}

Si je compile ce programme en utilisant un compilateur moderne (GCC), il donne l'avertissement. Un tel avertissement peut ne pas être très évident si nous travaillons avec le vrai code de production complexe.

main.cpp: Dans la fonction 'int main ()':

main.cpp: 4: 8: avertissement : 'x' est utilisé non initialisé dans cette fonction [-Wuninitialized]

y + = x;

    ^

================================================== =============================== Maintenant, si nous changeons notre programme qui utilise auto , puis compilons nous obtenons ce qui suit:

int main() {
    auto x;
    auto y = 0;
    y += x;
}

main.cpp: Dans la fonction 'int main ()':

main.cpp: 2: 10: erreur : la déclaration de 'auto x' n'a pas d'initialiseur

 auto x;

      ^

Avec auto, il n'est pas possible d'utiliser la variable non initialisée. C'est un avantage majeur que nous pouvons obtenir (gratuitement) si nous commençons à utiliser auto .

Ce concept et d'autres grands grands concepts C ++ modernes sont expliqués par Herb Shutter, expert C ++, dans son discours sur CppCon14 :

Retour à l'essentiel! Essentiels du style C ++ moderne

Un danger que j'ai noté concerne les références. par exemple

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

Le problème est que another_ref n'est pas réellement une référence dans ce cas, c'est MyBigObject au lieu de MyBigObject &. Vous finissez par copier un gros objet sans vous en rendre compte.

Si vous obtenez une référence directement à partir d'une méthode, vous pourriez ne pas penser à ce qu'elle est réellement.

auto another_ref = function_returning_ref_to_big_object();

vous auriez besoin de "auto &" ou "const auto &"

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

Utilisez autolà où il est logique qu'un type soit déduit. Si vous savez que quelque chose est un entier ou que vous savez que c'est une chaîne, utilisez simplement int / std :: string, etc. ou obscurcit le code.

C'est mon avis de toute façon.

autoLe mot clé ne peut être utilisé que pour une variable locale, pas pour des arguments ou des membres de classe / structure. Il est donc sûr et viable de les utiliser où vous le souhaitez. Je les utilise beaucoup. Le type est déduit au moment de la compilation, le débogueur affiche le type pendant le débogage, le sizeofsignale correctement, decltypeil donnerait le type correct - il n'y a pas de mal. Je ne compte pas autocomme surutilisé, jamais!

TL; DR: Voir la règle générale en bas.

La réponse acceptée suggère la règle empirique suivante:

Utilisation auto chaque fois qu'il est difficile de dire comment écrire le type à première vue, mais le type du côté droit d'une expression est évident.

Mais je dirais que c'est trop restrictif. Parfois, je ne me soucie pas des types, car la déclaration est suffisamment informative sans que je prenne la peine de prendre le temps de comprendre le type. Qu'est-ce que je veux dire par là? Prenons l'exemple qui est apparu dans certaines des réponses:

auto x = f();

Qu'est-ce qui en fait un exemple d'utilisation abusive auto? Est-ce mon ignorance du f()type de retour de? Eh bien, cela pourrait effectivement aider si je le savais, mais - ce n'est pas ma principale préoccupation. Ce qui est beaucoup plus problématique, c'est cela xet f()n'a pas beaucoup de sens. Si nous avions:

auto nugget = mine_gold();

au lieu de cela, alors je ne me soucie généralement pas de savoir si le type de retour de la fonction est évident ou non. En lisant la déclaration, je sais ce que je fais et j'en sais assez sur la sémantique de la valeur de retour pour ne pas ressentir le besoin de connaître également son type.

Donc ma réponse est: à utiliser autochaque fois que le compilateur le permet, à moins que:

• Vous pensez que le nom de la variable et l'expression d'initialisation / affectation ne fournissent pas suffisamment d'informations sur ce que fait l'instruction.
• Vous pensez que le nom de la variable ainsi que l'expression d'initialisation / affectation fournissent des informations "trompeuses" sur ce que le type devrait être - c'est-à-dire, si vous deviez deviner ce qui vient au lieu de l'automobile, vous seriez en mesure de faire une supposition - et ce serait mal, et cette fausse supposition a des répercussions plus tard dans le code.
• Vous souhaitez forcer un type différent (par exemple une référence).

Et aussi:

• Préférez donner un nom significatif (qui ne contient pas le nom du type bien sûr) avant de le remplacer autopar le type concret.

Une de mes amères expériences avec autoson utilisation avec des expressions lambda :

auto i = []() { return 0; };
cout<<"i = "<<i<<endl; // output: 1 !!!

En fait, ici iest résolu de fonctionner le pointeur de int(*)(). C'est juste un simple cout, mais imaginez quel type d'erreurs de compilation / d'exécution incorrectes il peut provoquer lorsqu'il est utilisé avec template.

Vous devez éviter auto avec de telles expressions et mettre un returntype approprié (ou contrôlé decltype())

L'utilisation correcte pour l'exemple ci-dessus serait,

auto i = []() { return 0; }(); // and now i contains the result of calling the lambda