Est-il un inconvénient à ce que déclarer des variables avec l'auto en C++?

Il semble que auto était une assez bonne fonctionnalité à ajouter dans C++11 qui semble suivre beaucoup de nouveaux langages. Comme avec un langage comme Python, je n'ai vu aucune déclaration explicite des variables (je ne suis pas sûr si c'est possible à l'aide de Python normes).

Est-il un inconvénient à l'utilisation de auto de déclarer les variables au lieu de déclarer explicitement eux?

InformationsquelleAutor DxAlpha | 2016-01-13
  1. 110

    Vous avez des questions sur les inconvénients, je suis donc de mettre en lumière certaines de celles-ci. Lorsque bien utilisé, auto a plusieurs avantages. Les inconvénients raison de la facilité d'abus, et de l'augmentation du potentiel de code à se comporter de manière non intentionnelle.

    Le principal inconvénient est que, en utilisant auto, vous ne savent pas forcément le type de l'objet créé. Il y a aussi des occasions où le programmeur pourrait s'attendre à ce que le compilateur pour en déduire un type, mais le compilateur catégoriquement en déduit une autre.

    Donné une déclaration comme

    auto result = CallSomeFunction(x,y,z);

    vous n'avez pas nécessairement besoin de la connaissance de ce type de result est. Il pourrait être un int. Il pourrait être un pointeur. Il pourrait être quelque chose d'autre. Tous ceux qui prennent en charge différentes opérations. Vous pouvez également changer de façon radicale le code par un changement mineur comme

    auto result = CallSomeFunction(a,y,z);

    parce que, selon ce que les surcharges existent pour CallSomeFunction() le type de résultat peut être complètement différent - et suivantes code peut donc se comporter d'une manière complètement différente que prévu. Vous pourriez soudainement déclencher des messages d'erreur plus tard dans le code(par exemple, par la suite essayer de déréférencer un int, d'essayer de changer quelque chose qui est maintenant const). Le plus sinistre, le changement est là que votre changement de voiles passé le compilateur, mais à la suite de code se comporte dans différentes et inconnues - éventuellement buggy - façons.

    De ne pas avoir les connaissances explicites du type de certaines variables par conséquent, il est plus difficile de justifier rigoureusement une revendication que le code fonctionne comme prévu. Cela signifie plus d'efforts pour justifier les allégations de "fit for purpose" en haute-criticité (par exemple essentiels à la sécurité ou à la mission-critique) domaines.

    Les autres, les plus courants inconvénient, c'est la tentation pour un programmeur d'utiliser auto comme un instrument contondant, à force de code à compiler, plutôt que de penser à ce que fait le code, et de travail pour obtenir ce droit.

    • Il est intéressant de noter que si ces exemples de l'inconvénient de l'utilisation de auto, alors la plupart de canard tapé langue subir de tels inconvénient par conception de!
    • Si CallSomeFunction() retourne un type différent selon la séquence de ses arguments, c'est un défaut de conception de CallSomeFunction(), pas un problème de auto. Si vous n'avez pas lu la documentation d'une fonction que vous utilisez avant de l'utiliser, c'est un des défauts de la programmeur, pas un problème de auto. - Mais je comprends que vous êtes jouer l'avocat du diable ici, c'est juste que Nir Friedman a la meilleure affaire.
    • Pourquoi T CallSomeFunction(T, int, int) être un défaut de conception? Évidemment, il "retourne un type différent selon la séquence de ses arguments."
    • Mettre votre exemple avec Pierre exemple dans un bécher et de lui donner une secousse, nous nous retrouvons avec un exemple où nous sommes déplaçant autour de trois ints'. 😉 Mais je vois d'où vous venez, et de reporter à mon deuxième point: Ne pas utiliser une fonction sans avoir lu sa documentation. 😉
    • dans la plupart des Ide modernes vous obtenez plus d'informations sur le type de variable lorsque vous placez le pointeur dessus, même l'auto annoncés
    • oui, il existe des inconvénients à l'utilisation de ces caractéristiques de canard-type de langues. De telles caractéristiques ne sont pas applicables à tous les problèmes. Oui, les canards de marcher, de nager, et charlatan. Mais pas tout ce qui fait ces choses est un canard.
    • les fonctions surchargées peuvent avoir différents types de retour, selon le type de leurs arguments. Ce n'est pas toujours un défaut de conception. Une source commune de bugs (en fait, beaucoup de débutants questions sur DONC) se font simplement par quelqu'un n'ayant pas lu la documentation, même de la bibliothèque standard les fonctions qu'ils utilisent et auto est une fonction - comme beaucoup d'lorsque mal utilisés - qui permet à un programmeur pour obtenir le code défectueux passé un compilateur. Je traite potentiel de mésusage comme un inconvénient.
    • Le plus insidieux de l'exécution problème serait si un flotteur est substitué avec un int, et plus tard de code silencieusement perd en précision.
    • "Le principal inconvénient est que, en utilisant auto, vous ne savent pas forcément le type de l'objet créé." Pouvez-vous expliquer pourquoi c'est un problème avec auto, et non pas un problème avec les sous-expression temporaires? Pourquoi est - auto result = foo(); mauvais, mais foo().bar() pas?
    • Je dirais qu'il est AUSSI un inconvénient de sous-expression temporaires.
    • Il semble d'après les commentaires que "inconvénient" est interprété comme une raison que quelque chose est inacceptable. Un inconvénient d'une fonctionnalité du langage est un inconvénient que le développeur doit examiner et de justifier de l'acceptation ou de non - savoir faire de l'ingénierie de compromis. Je ne fais pas les réclamations générales sur le pourquoi de la fonction doit ou ne doit pas être utilisé.
    • de plus sinistre, le changement est là que votre changement de voiles passé le compilateur, mais à la suite de code se comporte dans différentes et inconnues - éventuellement buggy - façons. Si il a navigué passé le compilateur, cela signifie que votre type de code-vérifié. Si le comportement de votre programme modifié, cela signifie que le type explicite de votre variable a été induisant une conversion implicite. La conversion doit être déclarée explicit, ou une autre expression est définie dans une sémantique de manière incohérente. En bref, quelque chose de suspect et vous feriez mieux de savoir quoi.
    • Ne pas se disputer avec qui, Laurent.
    • J'ai pensé que vous ne seriez pas 🙂 Cette phrase dans votre réponse est en fait juste, et je suis d'accord avec elle. Je plaide pour la main-wavily utilisation auto partout dans le nouveau code, mais être prudent lors de la modification d'un mot explicite de la déclaration de type de auto dans le code de legs.
    • c'est pourquoi l'initialisation uniforme a également été introduit. Un int ne peut pas être uniforme-initialisé à partir d'un flotteur.
    • Ceci. Tellement cette. Les gens se moquent de moi pour ne pas être un auto fanboy mais c'est un inconvénient sérieux, quand les gens écrivent partout sans réellement de la pensée.
    • Techniquement et peut-être malheureusement, certains croquis de définition de "peut", une int peut être initialisé à partir d'un float. La Norme ne prévoit qu'un diagnostic est émis lorsque le rétrécissement peut se produire lors de l'utilisation de l'accolade de l'initialisation. Il n'empêche pas nécessairement les compilateurs de la compilation du code. g++, par exemple, émet juste un avertissement... sans doute causer furieux débat entre ceux qui veulent une erreur de disque dur et ceux qui ne comprennent pas l'uniforme de l'initialisation et veux pas d'avertissement. modifier ah oui: gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
    • Malheureusement, en effet. Au moins G++5 produit une erreur lors de rétrécissement constant, et un avertissement autrement.

    InformationsquelleAutor Peter
  2. 75

    Ce n'est pas un inconvénient de auto dans un moyen de principes exactement, mais dans la pratique, il semble être un problème pour certains. Fondamentalement, certaines personnes soit: a) traiter auto comme un sauveur pour les types et les fermer leur cerveau lors de l'utilisation, ou b) oublier que auto toujours en déduit la valeur de types. Ce qui pousse les gens à faire des choses comme ça:

    auto x = my_obj.method_that_returns_reference();

    Oups, nous avons, d'une profondeur copié un objet. C'est souvent soit un bug ou d'une performance de l'échec. Ensuite, vous pouvez balancer dans l'autre sens aussi:

    const auto& stuff = *func_that_returns_unique_ptr();

    Maintenant, vous obtenez une balançant de référence. Ces problèmes ne sont pas causés par auto à tous, donc je ne considère pas leur bien-fondé des arguments contre elle. Mais il semble auto rend ces problème plus commun (à partir de mon expérience personnelle), pour les raisons que j'ai mentionnées au début.

    Je pense que compte tenu du temps les gens vont s'ajuster, et de comprendre la division du travail: auto en déduit le type sous-jacent, mais vous avez encore envie de penser à la référence-ness et const-ness. Mais c'est en prenant un peu de temps.

    • Pourquoi ne pouvez-vous copie en profondeur un cher objet pour commencer?
    • Certaines classes ont copier les constructeurs simplement parce qu'ils sont parfois nécessaires (par exemple, les instances de std::vector). D'être coûteux pour la copie n'est pas une propriété de classe, mais des objets individuels. Donc method_that_returns_reference peut se référer à un objet d'une classe qui a un constructeur de copie, mais l'objet qui se trouve être assez cher pour copier (et ne peut pas être déplacé à partir de).
    • Si l'objet est cher pour copier, et ne peut pas être déplacé, pourquoi serait-il être stocké dans un std::vector? (Parce qu'il en soit, oui, ou parce que vous n'avez pas le contrôle de la classe, mais ce n'est pas le point) Si c'est cher pour copier, (et ne possède pas de ressources, parce qu'il est copiable), pourquoi ne pas utiliser la VACHE sur l'objet? La localité des données est déjà tué par la taille de l'objet.
    • Pas une instance d'un élément stocké dans un vecteur d'être coûteux, juste un ex: vector<double> est cher pour copier, c'est un tas de répartition + O(N) de travail. Le déplacement est un leurre. La première ligne que j'ai montré la copie, ne pas bouger, à moins que la référence retournée est une référence rvalue. La VACHE est vraiment ni ici, ni là. Le fait est que cher pour copier des objets existera toujours.
    • Ils existent, accordée.
    • operator*()&& sur unique_ptr devrait probablement revenir un T pas un T&. Est-ce un défaut dans unique_ptr, exposés par votre exemple.
    • Il ne peut pas sécuritaire de le faire, parce qu'il pouvait trancher. La seule chose qu'il peut faire est de = delete la surcharge. Mais plus généralement ce que vous dites est une solution. C'est un sujet que j'ai déjà exploré, si vous êtes intéressé: nirfriedman.com/2016/01/18/....
    • Ah, blast, n'oubliez pas sur le découpage de là. Je veux vraiment que la "la durée de vie de la valeur de retour de cette fonction dépend de la durée de vie" (l'objet, les arguments) balisage, qui aurait permis à la fois de rapport d'erreur et peut-être permis une extension dans les cas où la durée de vie de l'extension est transitive.

    InformationsquelleAutor Nir Friedman
  3. 51

    D'autres réponses sont à mentionner les inconvénients comme "vous ne savez pas vraiment ce que le type d'une variable est." Je dirais que c'est en grande partie liée à la bâclée convention de nommage dans le code. Si vos interfaces sont clairement nommées, vous ne devriez pas avoir à soins ce que le type exact est. Bien sûr, auto result = callSomeFunction(a, b); ne pas vous en dire beaucoup. Mais auto valid = isValid(xmlFile, schema); vous dit assez pour utiliser valid sans avoir à se soucier de ce que son type exact est. Après tout, avec juste if (callSomeFunction(a, b)), vous ne connaissez pas le type que ce soit. De même avec toute autre sous-expression des objets temporaires. Donc, je ne considère pas cela un réel inconvénient de auto.

    Je dirais que son principal inconvénient est que, parfois, exactement le type de retour est pas ce que vous souhaitez travailler avec. En effet, parfois, le rendement réel de type diffère de la "logique" type de retour comme une mise en place/optimisation de détail. L'Expression des modèles en sont un excellent exemple. Disons que nous avons ceci:

    SomeType operator* (const Matrix &lhs, const Vector &rhs);

    Logiquement, nous nous attendons à ce SomeType être Vector, et nous tenons à le traiter comme tel dans notre code. Toutefois, il est possible que pour l'optimisation, l'algèbre de la bibliothèque, nous utilisons les met en œuvre l'expression de modèles et le type de retour est: est-ce

    MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

    Maintenant, le problème est que MultExpression<Matrix, Vector> veut dans toute la probabilité de stocker une const Matrix& et const Vector& en interne; il s'attend à ce qu'il va se convertir à une Vector avant la fin de sa pleine expression. Si nous avons ce code, tout est bien:

    extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  //do something with res
}

    Cependant, si l'on avait utilisé auto ici, nous avons pu mettre en difficulté:

    void compute()
{
  auto res = a * (b * (c * v));
  //Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}
    • C'est une légitime exemple, ne m'obtenez pas le mal, mais l'expression des modèles et des procurations en général sont relativement rares. Je pense que dans une assez grande partie du code, je n'ai jamais vu une procuration à l'extérieur de la matrice des bibliothèques et de l'abomination qui est vector<bool>. Donc dire que c'est le principal inconvénient est forte. Edit: juste pour préciser, je ne suis PAS le downvoter :-).
    • Vous avez raison, c'est fort, mais j'ai vraiment le sentiment que auto a très peu d'inconvénients, si je m'en tiens qu'à force. Et d'autres exemples de procurations, etc. comprennent divers "string " constructeurs" et autres objets trouvés dans les Dsl.
    • J'ai été mordu par l'expression des modèles et des auto le passé, en particulier avec les modes Propres de la bibliothèque. Il est particulièrement difficile parce que le problème n'est souvent pas dans les versions de débogage.
    • Le problème de ne pas savoir le type peut être évité avec la notation hongroise.
    • L'utilisation de auto peut aussi mordre lors de l'utilisation de la Tatou de la matrice de la bibliothèque, qui fait une utilisation intensive du modèle de méta-programmation à des fins d'optimisation. Heureusement, les développeurs ont ajouté .eval() une fonction qui peut être utilisé pour éviter les problèmes avec auto
    • Remarque: auto valid = isValid(...) est pas plus courte que bool valid = isValid(...)!
    • L'affirmation *"vous ne savez pas vraiment ce que le type d'une variable est." * est correct. Quand vous avez écrit le code, tu le savais (si vous avez voulu savoir) ce que le type a été. Maintenant que peu de temps a passé et que quelqu'un a mis quelque chose, vous pensez que vous savez le type ou que c'est ce que vous vous souvenez, mais vous ne savez pas, parce que quelqu'un a peut-être changé la source de son type. Je suis d'accord avec le reste de votre post.
    • mais ne isValid vraiment revenir un bool, ou est-il une conversion se passe?
    • "Si vos interfaces sont clairement nommées, vous ne devriez pas besoin de se soucier de ce que le type exact est", le compilateur ne peut pas vérifier l'exactitude de votre code, par l'étude des noms de variables. C'est l'ensemble de point d'un système de type. Aveuglément en contournant c'est stupide!
    • Je n'ai pas fait de statistiques, mais je dirais que la plupart des expressions typiques de code contient plusieurs sans nom temporaires (dont le type est, par définition, pas énoncé explicitement) pour chaque définition d'une variable nommée (dont le type pourrait être énoncée de manière explicite). Si ce n'est pas un problème pour les temporaires locales à une expression, pourquoi est-ce un problème pour le nom des variables locales d'une fonction?
    • Ce n'est pas un problème pour les temporaires parce que vous êtes généralement immédiatement de les utiliser, ce qui, sans auto implique généralement un certain type de contrôle de type (et les éclaboussures auto dans l'emmène partout que le type de sécurité à l'écart, comme il le fait partout ailleurs). Ce n'est pas une bonne comparaison.

    InformationsquelleAutor Angew
  4. 13

    Un des inconvénients est que, parfois, vous ne pouvez pas déclarer const_iterator avec auto. Vous obtiendrez ordinaires (non const) itérateur dans cet exemple de code à partir de cette question:

    map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");
    • Eh bien, vous obtenez une iterator dans tous les cas, depuis votre carte est non-const. si vous voulez convertir à un const_iterator, spécifiez le type de variable explicitement comme d'habitude, ou extraire une méthode afin que votre carte est const dans le cadre de votre find. (Je préfère ce dernier. PÉR.)
    • auto city_it = static_cast<const auto&>(map).find("New York") ? ou, avec le C++17, auto city_if = std::as_const(map).find("New York").
    InformationsquelleAutor ks1322
  5. 11

    Il rend votre code un peu plus difficile ou fastidieux à lire.
    Imaginez quelque chose comme ça: 

    auto output = doSomethingWithData(variables);

    Maintenant, de déterminer le type de sortie, vous devez traquer la signature de doSomethingWithData fonction.

    • Pas toujours. auto it = vec.begin(); est beaucoup plus facile à lire que std::vector<std::wstring>::iterator it = vec.begin(); par exemple.
    • D'accord. Cela dépend du cas d'utilisation. J'aurais pu être plus précis à ce sujet.
    • ouais, les gens qui sont l'utilisation de l'auto que de faire le mal.
    • "La piste en bas de la signature de la fonction", si ce n'est'tisn pas un survolés par la souris ou une touche de loin ("suivi du symbole"/" aller à la déclaration"/quelque soit le nom de), vous devez configurer votre éditeur de plus ou de basculer vers un IDE qui peut faire cela sans configuration..., Votre point est toujours valide, cependant.
    • J'ai remarqué que pas dans un IDE, mais en petites judas optiques des différences lors de l'examen des archivages! Avec l'auto, ils sont plus difficiles à lire pour cette raison.
    • non, ils sont en train de faire la plupart du temps, parce que pas de conversion implicite est impliqué, et output est toujours le bon type pour stocker la valeur de retour. Ensuite, si il ya un besoin pour une conversion, j'aimerais spécifier le type exact, ou en fonte. Mais je ajouter quelque chose pour le code que s'il y a quelque chose de louche comme une nécessaire conversion implicite en cours. Mais je suis d'accord que c'est dur d'avoir une indication sur le type exact de la variable avec des noms comme auto, output doSomethingWithData et variables.
    • Si l'auteur de doSomethingWithData devrait ont pris le soin d'appeler sa méthode crossProductOf(variables), le retour de type aurait été hors de propos.

    InformationsquelleAutor Skam
  6. 9

    Comme cette développeur, je déteste auto. Ou plutôt, je déteste la façon dont les gens de mauvaise utilisation auto.

    Je suis de la (forte) de l'opinion que auto est pour vous aider à écrire du code générique, non pas pour réduire tapant.

    C++ est un langage dont le but est de vous permettre d'écrire du code robuste, pas afin de minimiser le temps de développement.

    C'est assez évident, d'après de nombreuses fonctionnalités de C++, mais malheureusement quelques-uns des plus récents comme auto que de réduire la frappe induire les gens en erreur en pensant qu'ils devraient commencer à être paresseux à taper.

    En pré-auto jours, les gens typedefs, qui était bien parce que typedef a permis au concepteur de la bibliothèque pour vous aider à déterminer quel est le type de retour doit être, de sorte que leur bibliothèque fonctionne comme prévu. Lorsque vous utilisez auto, vous emporter que le contrôle à partir de la classe de concepteur et au lieu de demander à la compilateur de comprendre ce type devrait être, ce qui supprime l'un des plus puissants C++ outils de la boîte à outils et les risques rupture leur code.

    En règle générale, si vous utilisez auto, elle doit être parce que votre code fonctionne pour tout raisonnable de type, pas parce que vous êtes tout simplement trop paresseux pour écrire le type qu'il devrait travailler avec.
    Si vous utilisez auto comme un outil d'aide à la paresse, puis ce qui se passe est que vous avez éventuellement commencer à introduire bogues subtils dans votre programme, généralement causée par des conversions implicites qui ne se produisent pas parce que vous avez utilisé auto.

    Malheureusement, ces bugs sont difficiles à illustrer dans un court exemple ici en raison de leur brièveté rend moins convaincante que les exemples qui viennent d'un utilisateur projet -- cependant, ils se trouvent facilement dans un modèle lourd code qui s'attendent à certains conversions implicites à prendre place.

    Si vous voulez un exemple, il y a un ici. Une petite remarque, cependant: avant d'être tenté de sauter et de critiquer le code: gardez à l'esprit que de nombreux bien connu et mature bibliothèques ont été développées autour de ces conversions implicites, et ils sont là parce qu'ils résoudre les problèmes qui peut être difficile si pas impossible à résoudre autrement. Essayez de trouver un meilleure solution avant de les critiquer.

    • which was great because typedef allowed the designer of the library to help you figure out what the return type should be, so that their library works as expected. When you use auto, you take away that control from the class's designer and instead ask the compiler to figure out what the type should be Pas vraiment une bonne raison de l'OMI. Up-to-date de l'IDE, Visual Studio 2015 par exemple, vous permettent de vérifier le type de la variable en survolant auto. C'est *exactement* le même que le typedef un.
    • Il vous manque plusieurs points cruciaux, il y a: (1) Votre IDE argument ne fonctionne que si le type est en béton, et non pas basé sur un modèle. IDEs ne peut pas vous dire le type correct dans le cas de types de charge, par exemple typename std::iterator_traits<It>::value_type. (2) Le tout le point est que le type inféré besoin de pas être "exactement le même" que le bon type prévu par le précédent concepteur du code; en utilisant auto, vous prenez loin le concepteur de la possibilité de spécifier le type correct.
    • Vous êtes essentiellement parler de procurations, dont une des réponses mentionne déjà. L'Expression de modèles et de vector<bool> non-sens ne sont pas tous les jours de code pour la plupart des gens. Dans la plupart des situations, vous ne pas vous voulez des conversions implicites, auto et vous aide à cela. Herb Sutter discussions sur les avantages de l'auto largement dans un de ses messages de blog, et ce n'est pas principalement sur les frappes, et il n'est également pas juste pour le générique de code. Aussi, le premier lien que vous avez fourni, le blog est tout simplement terrible conseils (qui est pourquoi il est critiqué de façon virulente dans ses commentaires de l'article).
    • non-sens"... pardon? Comment pensez-vous bitset est mis en œuvre? Ou considérez-vous peu des conteneurs non-sens tout à fait?!
    • Vector<bool> est un non-sens, pour les raisons exposées à la mort déjà, et cela est largement consensus. Bitsets n'avez pas besoin d'un proxy pour quoi que ce soit, vous pouvez simplement utiliser jeu et le tester. L'opérateur[] pour de tels conteneurs sucre syntaxique qui n'est pas vraiment la peine à mon humble avis.
    • J'aime la façon dont vous rejeter bitset de l'opérateur [], avec "a mon avis" quand c'est un contre-exemple clair de votre myope licenciement de vector<bool> problème...
    • Je ne suis pas rejeter quoi que ce soit, simplement en indiquant que c'est du sucre syntaxique. Quelle est la valeur ajoutée réelle de l'aide de l'opérateur[] sur set/test? Les procurations sont problématiques; elles sont sources de complexité et ils ne jouent pas bien avec le type de déduction en général. Les problèmes ne sont pas spécifiques à l'automobile, ils s'appliquent aux modèles ainsi. Les procurations doivent être utilisés uniquement lorsqu'ils donnent beaucoup de valeur. Expression de la matrice de modèles de faire. Bitset sucre syntaxique qui ne fonctionne pas. Une discussion des raisons pour lesquelles vector<bool> était une mauvaise idée, puisque apparemment sa nouvelle pour vous: gotw.ca/publications/N1185.pdf
    • Rien vector<bool> sont des nouvelles de moi. Ce que j'essaie de vous dire et que vous êtes manifestement en refusant de comprendre, c'est que, pour les fins de cette question bitset n'est pas différent de vector<bool> -- deux d'entre eux utilisent des proxys, parce que les procurations ont été réputé pour être utile, et le fait que les procurations sont utiles, c'est une réalité, vous devez accepter au lieu de vivre dans le déni de la. Pouvez vous s'il vous plaît arrêter de le transformer en un débat quant à savoir si vous pensez que les procurations sont utiles? Ce n'est pas le sujet du débat, et aussi, votre opinion est juste ton avis, pas une sorte de fait.
    • Heureux, il n'est pas nouvelles pour vous, voici un cookie pour le savoir! Ce que j'essaie de vous dire c'est que la très grande majorité du temps, les gens ne sont pas en utilisant des proxys. Les gens en fait activement les éviter dans de nombreux cas. En tout cas, voici une autre opinion de vous: tout ce qui est dans votre réponse est déjà couvert par une autre réponse, à l'exception de mieux. Alors peut-être vous devriez juste upvote Angew de réponse si vous ne l'avez pas déjà, et de supprimer la vôtre? Grand de parler, d'avoir une belle journée.
    • Ma réponse explique les choses différemment, et je pense que mon explication a de la valeur, donc je ne vois pas pourquoi je devrais le supprimer. Et merci pour le cookie et le downvote de la frustration, de toute évidence vous faire vraiment vraiment excellente contribution à ce site.
    • Mehrdad, @NirFriedman: je pense Nir à propos de ce que les gens font habituellement/est la plupart du temps pas un argument très convaincant... la plupart des gens la plupart du temps à faire des choses que vous n'avez pas les voir ou de les entendre (car ils ne sont pas dans les plus couramment utilisées bibliothèques); de plus, ce qu'ils font est très en forme, par conception, les décisions prises par le comité des normes et d'autres de la bibliothèque de designers. Pourtant, je pense que Mehrdad de la position sur le but de auto est trop extrême. Pensez à ce qui arrive lorsque, au lieu de auto x = foo(); bar(x); vous avez bar(foo()); - ici ainsi vous "réduire la frappe" et c'est parfaitement légitime.
    • Attendez, j'ai d'abord pensé que j'ai entendu, mais maintenant je suis confus en ce que la partie de ma position exactement vous êtes argumenter contre. Pouvez-vous donner un exemple plus complet? Quelles sont les définitions de foo et bar ici? (ce que vous voulez montrer?)

    InformationsquelleAutor Mehrdad
  7. 6

    auto n'a pas les inconvénients soi, et je plaide pour la main wavily) utilisation partout dans le nouveau code. Il permet à votre code constante de type case, et constamment éviter le silence de la découper. (Si B dérive de A et une fonction retournant A réapparaît subitement B, puis auto se comporte comme prévu pour stocker sa valeur de retour)

    Bien que, avant C++11 du code legacy peut compter sur les conversions implicites induits par l'utilisation de manière explicite-les variables de type. Changer explicitement de type de variable à auto peut modifier le code de comportement, de sorte que vous feriez mieux d'être prudent.

    • Downvoting est juste, mais pourriez-vous me dire pourquoi?
    • Je n'ai pas downvote vous, mais auto a des inconvénients en soi (ou au moins beaucoup pensent qu'il n'). Prenons l'exemple donné dans la deuxième question, ce forum avec de Sutter, Alexandrescu et Meyers: Si vous avez auto x = foo(); if (x) { bar(); } else { baz(); } et foo() retourne bool - ce qui se passe si foo() les modifications pour revenir un enum (trois options au lieu de deux)? Le auto code continuera à fonctionner, mais de produire des résultats inattendus.
    • Et n'utilisant bool au lieu de auto changer quoi que ce soit dans le cas d'une non délimité enum? Je me trompe peut-être (ou ne peuvent pas voir ici), mais je pense que la seule différence est que la conversion à l' bool arrive à la déclaration de la variable à la place de l'évaluation de l'état dans le if. Si le enum est étendu, puis conversion en bool ne doit pas se faire sans un avis précis.
    InformationsquelleAutor Laurent LA RIZZA
  8. 4

    Mot-clé auto simplement en déduire le type de la valeur de retour. Par conséquent, il n'est pas équivalent à un objet Python, par exemple

    # Python
a
a = 10       # OK
a = "10"     # OK
a = ClassA() # OK

//C++
auto a;      //Unable to deduce variable a
auto a = 10; //OK
a = "10";    //Value of const char* can't be assigned to int
a = ClassA{} //Value of ClassA can't be assigned to int
a = 10.0;    //OK, implicit casting warning

    Depuis auto est déduite lors de la compilation, il ne dispose d'aucun inconvénient au moment de l'exécution que ce soit.

    • oui, il ne fait que type() en python n'. Il en déduit le type, il n'est pas de créer une nouvelle variable de ce type.
    • En fait, ce serait decltype. auto est pour l'attribution de la variable en particulier.
    InformationsquelleAutor Leben Asa
  9. 4

    Ce que personne n'a mentionné jusqu'ici, mais pour lui-même mérite une réponse, si vous me demandiez.

    Depuis (même si chacun doit être conscient que C != C++) du code écrit en C peut facilement être conçu de manière à fournir une base pour le code C++ et donc être conçu sans trop d'effort, être en C++ compatible, cela pourrait être une exigence pour la conception.

    Je sais à propos de certaines règles bien définies constructions de C ne sont pas valides pour C++ et vice versa. Mais ce serait tout simplement cassé les exécutables et à l'UB-clause s'applique, ce qui la plupart du temps est remarqué par d'étranges loopings résultant dans des accidents ou que ce soit (ou même peut rester inaperçus, mais qui n'a pas d'importance ici).

    Mais auto est la première fois1 cela change!

    Imaginez que vous avez utilisé auto que le stockage de classe spécificateur avant et transférer le code. Il ne serait même pas nécessairement (selon la manière dont il a été utilisé) "pause"; en fait, il pourrait silencieusement modifier le comportement du programme.

    C'est quelque chose qu'on doit garder à l'esprit.

    1Au moins la première fois que je suis au courant.

    • Vous obtiendrez une erreur de compilation, de toute façon lorsque vous essayez de compiler.
    • Ce qui permettrait de le faire? pourquoi devrait-2 code valide situations avec différents sens resutl jamais dans l'erreur?
    • Si vous êtes en s'appuyant sur "pas de type implique int" en C, vous méritez toutes les mauvaises choses que vous aurez à partir de ce. Et si vous n'êtes pas en s'appuyant sur elle, à l'aide de auto comme une classe de stockage spécificateur de à côté d'un type vous donnera une belle erreur de compilation en C++ (qui est une Bonne Chose dans ce cas).
    • eh bien c'est le cas, je suis référant à un, oui. je suis ne pas faire cela. Mais c'est quelque chose qui devrait au moins être gardé à l'esprit.
    InformationsquelleAutor dhein
  10. 2

    Comme je l'ai décrit dans cette réponse auto peut parfois entraîner funky situations, vous n'avez pas l'intention.
    Vous devez explicitement dire auto& d'avoir un type de référence, tout en faisant juste auto pouvez créer un type de pointeur. Cela peut entraîner de la confusion en omettant le spécificateur tous ensemble, résultant en une copie de la référence au lieu d'un réel de référence.

    • Ce n'est pas funky. C'est ce que auto ne, jamais déduire une référence ni const type. Pour un auto de référence, vous feriez mieux d'utiliser auto&&. (une référence universelle) Si le type n'est pas bon marché pour le copier ou le propriétaire d'une ressource, le type ne doit pas être copiable pour commencer.
    InformationsquelleAutor Sombrero Chicken
  11. 2

    Une raison que je peux penser, c'est que vous perdez la possibilité de contraindre la classe qui est retournée. Si votre fonction ou de la méthode retourné une longue 64 bits, et vous ne voulait 32 unsigned int, alors vous perdez la possibilité de le contrôler.

    • Il y a static_cast, et autant que je me souvienne par exemple Meyers Moderne et Efficace de C++ même recommande de l'utiliser pour spécifier le type auto, de type de variable.
    InformationsquelleAutor kblansit
  12. 1

    Un autre irritant exemple:

    for (auto i = 0; i < s.size(); ++i)

    génère un avertissement (comparison between signed and unsigned integer expressions [-Wsign-compare]), parce que i est une signature de type int. Pour éviter cela, vous devez écrire par exemple

    for (auto i = 0U; i < s.size(); ++i)

    ou peut-être mieux:

    for (auto i = 0ULL; i < s.size(); ++i)
    • Oui je la trouve trop irritant. Mais le trou dans la langue est quelque part d'autre. Pour que ce code puisse être réellement portable, en supposant size retourne size_t, vous devriez être en mesure d'avoir un size_t littéral comme 0z. Mais vous pouvez déclarer un UDL pour ce faire. (size_t operator""_z(...))
    • Purement théorique objections: unsigned est tout à fait susceptibles de ne pas être presque assez grand pour contenir toutes les valeurs de std::size_t sur les architectures, donc dans le cas peu probable que quelqu'un a eu un récipient avec un univers gigantesque nombre d'éléments, à l'aide de unsigned pourrait provoquer une boucle infinie sur le bas de la fourchette d'indices. Tout cela est peu être un problème, std::size_t doit être utilisé pour obtenir un code propre correctement les signaux de l'intention. Je ne suis pas sûr que même unsigned long long est strictement garanti suffire, bien que dans la pratique, il doit sans doute être la même.
    • oui, juste à point unsigned long long est assuré d'être au moins 64 bits, mais en théorie size_t pourrait être plus grand que cela, je suppose. Bien sûr, si vous avez > 2^64 éléments dans votre conteneur ensuite, vous pouvez avoir plus de problèmes à s'inquiéter... 😉
    InformationsquelleAutor Paul R
  13. 1

    Je pense que auto est bien localisé dans un contexte, où le lecteur facilement & évidemment, peut déduire de son type, ou bien documenté avec un commentaire de son type ou un nom qui en déduire le type réel. Ceux qui ne comprennent pas comment cela fonctionne peut prendre dans le mauvais moyens, à l'instar de l'utiliser à la place de template ou similaire. Voici quelques bonnes et mauvaises des cas d'utilisation à mon avis.

    void test (const int & a)
{
    //b is not const
    //b is not a reference

    auto b = a;

    //b type is decided by the compiler based on value of a
    //a is int
}

    Bons Usages

    Itérateurs

    std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int> v();

..

std::vector<boost::tuple<ClassWithLongName1,std::vector<ClassWithLongName2>,int>::iterator it = v.begin();

//VS

auto vi = v.begin();

    Pointeurs De Fonction

    int test (ClassWithLongName1 a, ClassWithLongName2 b, int c)
{
    ..
}

..

int (*fp)(ClassWithLongName1, ClassWithLongName2, int) = test;

//VS

auto *f = test;

    De Mauvais Usages

    De Flux De Données

    auto input = "";

..

auto output = test(input);

    Signature De Fonction

    auto test (auto a, auto b, auto c)
{
    ..
}

    Cas Triviaux

    for(auto i = 0; i < 100; i++)
{
    ..
}
    • Lorsque vous souhaitez une int, vous devez taper un plus char, si vous allez pour auto. C'est inacceptable
    • oui, c'est un int aussi facilement vu ici & tapant int est plus courte. C'est pourquoi il est un cas trivial.
    InformationsquelleAutor Khaled.K