C++11, varient en fonction de boucle: obtenir l'élément par valeur ou par référence à const

La lecture de quelques exemples de gamme à base de boucles, ils suggèrent deux principales façons Un, Deux, Trois, Quatre

std::vector<MyClass> vec;

for (auto &x : vec)
{
  //x is a reference to an item of vec
  //We can change vec's items by changing x 
}

ou

for (auto x : vec)
{
  //Value of x is copied from an item of vec
  //We can not change vec's items by changing x
}

Bien.

Lorsque nous n'avons pas besoin de changer vec éléments, de l'OMI, des Exemples suggèrent d'utiliser la deuxième version (en valeur). Pourquoi ils n'ont pas de proposer quelque chose qui const références (Au moins je n'ai pas trouvé toute suggestion directe):

for (auto const &x : vec) //<-- see const keyword
{
  //x is a reference to an const item of vec
  //We can not change vec's items by changing x 
}

N'est-il pas mieux? N'est-il pas d'éviter une copie redondante dans chaque itération alors que c'est une const?

InformationsquelleAutor masoud | 2013-03-02
  1. 350

    Si vous ne voulez pas modifier les éléments ainsi que voulez éviter de faire des copies, puis auto const & est le bon choix:

    for (auto const &x : vec)

    Celui qui vous propose d'utiliser auto & est faux. Les ignorer.

    Voici un rappel:

    • Choisir auto x quand vous voulez travailler avec des copies.
    • Choisir auto &x quand vous voulez travailler avec des éléments d'origine et peut les modifier.
    • Choisir auto const &x quand vous voulez travailler avec des éléments d'origine et de ne pas les modifier.
    • Merci pour la réponse très. Je suppose qu'il doit également être souligné que const auto &x est équivalent à votre troisième choix.
    • auto &x n'est pas équivalent à auto const &x, mais c'est la même syntaxe. C'est juste que ce dernier est plus claire et lisible de mise en forme.
    • C'est équivalent. (et que voulez-vous dire par "mais c'est la même syntaxe"? La syntaxe est observable différents.)
    • Manquant: auto&& lorsque vous ne voulez pas faire un inutile copie, et ne se soucient pas si vous le modifiez ou pas, et vous voulez juste travailler.
    • Je veux dire, la norme ne spécifie pas les deux syntaxes alternatives (aucune OU ed BNF), mais décrit un où cv-qualifers peut être librement mélangés dans decl-spécificateur-seq. <pédant>Pour moi, "équivalent" signifie fermer, mais pas nécessairement les mêmes, alors que ces deux formes sont exactement les mêmes.</pédant>
    • La référence distinction s'appliquent aux copies si vous êtes juste de travailler avec des types fondamentaux, comme int/double?
    • référence distinction s'appliquent aux copies" ne fait pas de sens pour moi. Qu'entendez-vous par là? Comme pour ce que j'ai dit dans la réponse, s'applique à TOUS les types fondamentaux ainsi types définis par l'utilisateur.
    • Désolé, c'était mal formulé. Je suis curieux de savoir la vitesse. Si je ne vais pas être la modification d'un int est-il préférable de travailler avec des copies ou des const références lors de l'utilisation d'une gamme à base de? À la fois de protéger la valeur d'origine de la modification, mais qui est le plus performant approche.
    • Je ne peux pas commenter sur le ensemble de la vitesse, et je pense que personne ne peut, sans le profilage d'abord. Franchement, je n'ai pas la base de mon choix sur la vitesse plutôt que la clarté du code. Si je veux l'immuabilité, j'utiliserais const pour vous. Toutefois, s'il serait auto const &, ou auto const a peu de différence. Moi je préfère auto const & juste pour être plus cohérent.
    • Une autre bonne raison pour l'utilisation de const auto & sur const auto est que le point de l'ensemble de l'auto est ainsi que si vous modifiez le type que vous n'avez pas à modifier la déclaration... qui signifie que si c'était un type de base et vous faire un gros complexe de classe, vous n'aurez pas à le changer pour éviter la copie qu'il était en train de faire.

    InformationsquelleAutor Nawaz
  2. 21

    Si vous avez un std::vector<int> ou std::vector<double>, alors il est acceptable d'utiliser auto (avec la valeur de la copie) au lieu de const auto&, depuis la copie d'un int ou un double est bon marché:

    for (auto x : vec)
    ....

    Mais si vous avez un std::vector<MyClass>, où MyClass a certains non-trivial sémantique de copie (par exemple,std::string, certains complexes de classe personnalisée, etc.) alors je vous suggérons d'utiliser const auto& pour éviter profonde des copies:

    for (const auto & x : vec)
    ....
    InformationsquelleAutor Mr.C64
  3. 3

    Lorsque nous n'avons pas besoin de changer vec articles, Exemples suggèrent d'utiliser la première version.

    Alors qu'ils donnent une mauvaise suggestion.

    Pourquoi ils n'ont pas de proposer quelque chose qui const références

    Car ils donnent une mauvaise suggestion 🙂 Ce que vous mentionnez est correct. Si vous ne voulez observer un objet, il n'est pas nécessaire de créer une copie, et il n'est pas nécessaire d'avoir un non-const référence.

    EDIT:

    Je vois les références lien fournissent tous des exemples de l'itération sur une plage de int valeurs ou de quelque autre type de données fondamental. Dans ce cas, puisque la copie d'un int n'est pas cher, la création d'une copie est essentiellement équivalent à (si pas plus efficace que l') ayant une observation const &.

    Ce n'est toutefois pas le cas en général pour les types définis par l'utilisateur. Udt peut être cher à la copie, et si vous n'avez pas une raison pour la création d'une copie (telles que la modification de l'objet récupéré, sans altérer l'original), alors il est préférable d'utiliser un const &.

    • Pourriez-vous parler de ce que ceux sont les références?
    • Je reliés entre eux par des numéros dans ma question, (1)(2)...
    • Je ne vois aucune réponse de la vôtre...
    • OK, c'est parce que ceux sont des types fondamentaux comme int, et la copie de la valeur n'est pas cher. Fondamentalement, il fait le même effet qu'un const &.
    InformationsquelleAutor Andy Prowl
  4. 1

    Je vais être contraire ici et dire qu'il n'est pas nécessaire pour auto const & dans une gamme à base de boucle. Dites-moi si vous pensez que la fonction suivante est stupide (pas à ses fins, mais dans la façon dont il est écrit):

    long long SafePop(std::vector<uint32_t>& v)
{
    auto const& cv = v;
    long long n = -1;
    if (!cv.empty())
    {
        n = cv.back();
        v.pop_back();
    }
    return n;
}

    Ici, l'auteur a créé un const référence à v à utiliser pour toutes les opérations qui ne modifient pas v. C'est stupide, à mon avis, et le même argument peut être faite pour l'utilisation de auto const & que la variable dans une plage de base pour la boucle au lieu de simplement auto &.

    • Donc je peux en déduire que vous aussi, vous avez des arguments contre const_iterator dans une boucle for? Comment vous assurez-vous que vous ne modifiez pas les éléments d'origine à partir d'un conteneur lorsque vous effectuer une itération sur elle?
    • Dans une boucle for, j'utilise l'auto. En C++03, oui, je voudrais utiliser const_iterator, mais pas pour s'assurer que je n'ai pas modifier les éléments dans le conteneur. Je voudrais utiliser const_iterator parce que sinon il ne compile pas pour const conteneurs. Je n'ai pas besoin const_iterator pour s'assurer que je n'ai pas modifier des éléments dans un conteneur, parce que je n'écris pas de la boucle de corps si grand que leur but n'est pas évident au premier regard.
    • Pourquoi ton code ne compile sans const_iterator? Laissez-moi deviner, le récipient qui vous itérateur sur, est const. Mais pourquoi est-il const pour commencer? Quelque part, vous êtes à l'aide de const pour s'assurer que?
    • Parce que la fonction a reçu de cette façon.
    • Pourquoi ne pas le recevoir en tant que non-const de référence?
    • De sorte que const objets peuvent être passés à la fonction.
    • Quelles fonctions? Ces fonctions prennent argument const de référence? Mais pourquoi?
    • N'ai pas mon dernier commentaire réponse? Vous prenez un argument par référence const afin que const objets peuvent être passés à la fonction. Si vous prenez l'argument par des non-const de référence, const objets ne peuvent pas être transmis.
    • Pourquoi ces objets sont const pour commencer? Si vous les rendre non-const, alors vous n'avez pas à recevoir des arguments par const de référence. En gros, je me demande pourquoi utiliser const à tous?
    • Qui sait? Il existe une multitude de raisons pour faire un objet const. C'est à l'appelant de la compétence du, pas le mien. Je suis le seul de l'écriture de la fonction qui prend l'objet. Et si ma fonction ne modifie pas l'objet, il n'y a pas de raison de limiter arbitrairement en sorte que seuls les non-const objets peuvent être transmis.
    • Dans ce cas, vous rendre les objets const? Et pourquoi?
    • Avantage de rendre les objets const est comme les avantages de l'utilisation de private/protected dans les classes. Il évite des erreurs.
    • Je pense que la mise en œuvre de SafePop() est stupide seulement parce qu'il ne prend pas une référence à const en premier lieu. Mais en supposant que certains idiot patron a dit le programmeur "Cette fonction A pour cette signature, tout droit? Je ne m'inquiète pas si vous ne l'aimez pas!", ensuite, je dirais que le programmeur a fait un bon travail.
    • ne compile pas si la fonction prend une référence à const.
    • Oh, j'ai oublié que. Alors dans ce cas, la mise en œuvre est bête. Mais si cette fonction ne doit pas modifier v, la mise en œuvre serait bien de l'OMI. Et si la boucle ne modifie jamais les objets qu'il parcourt, il me semble bon pour moi d'avoir une ref à const. Je vois votre point de si. La mienne est que la boucle représente une unité de code un peu comme la fonction, et au sein de l'unité il n'y a pas d'instruction qui ont besoin de modifier la valeur. Par conséquent, vous pouvez "marquer" l'ensemble de l'unité const, comme vous le feriez avec un const de la fonction membre.
    • Si vous pensez que const & pour la gamme de base est stupide, parce que vous avez écrit une pertinence exemple imaginaire de imaginaire programmeur qui a fait quelque chose de stupide avec cv-qualification? ...OK, alors
    • Pourquoi pensez-vous que ce que l'imaginaire programmeur n'était idiot?
    • Parce qu'ils ont 2 références différentes pour le même objet (vaut mieux l'éviter dans et de lui-même) et plus particulièrement avec 2 cv-qualifications. Basés sur la plage, pour ne pas l'avoir, mais il t nous permettre d'éviter accidentellement modifier un devrait-être-const objet, tout comme un const & paramètre. Pourquoi pensez-vous que ce n'est pas utile? Je suis heureux que vous êtes un assez bon programmeur n'a pas besoin de l'erreur de compilation, mais sinon c'est vraiment une bonne sauvegarde et de l'indication de l'intention.
    • Regardez, j'écris le code que un beaucoup d'autres personnes vont regarder et modifier. En génie logiciel, il existe un concept de la 7 "-ilities" et c'est maintenance. Const correctness est un concept important dans la maintenabilité et que ce dont il s'agit.

    InformationsquelleAutor Benjamin Lindley