Pourquoi est-ce que C++11 lambda besoin “mutable” mot-clé pour la capture par valeur, par défaut?

Court exemple:

#include <iostream>

int main()
{
    int n;
    [&](){n = 10;}();             //OK
    [=]() mutable {n = 20;}();    //OK
    //[=](){n = 10;}();          //Error: a by-value capture cannot be modified in a non-mutable lambda
    std::cout << n << "\n";       //"10"
}

La question: Pourquoi avons-nous besoin de la mutable mot-clé? Il est tout à fait différent du traditionnel passage de paramètres à des fonctions nommées. Quelle est la logique derrière?

J'étais sous l'impression que le point de l'ensemble de la capture-par-valeur est de permettre à l'utilisateur de modifier le temporaire -- sinon, je suis presque toujours préférable d'utiliser la capture par référence, ne suis-je pas?

Tout enlightenments?

(Je suis en utilisant MSVC2010 par la voie. Autant que je sache, ce devrait être la norme)

  • Bonne question, bien que je suis content que quelque chose est enfin const par défaut!
  • Pas une réponse, mais je pense que c'est une chose sensée: si vous prenez quelque chose en valeur, vous ne devriez pas être en train de changer juste pour vous sauver 1 copie d'une variable locale. Au moins vous ne faites pas l'erreur de changement de n en remplaçant = avec &.
  • Je suis absolument d'accord avec stefaanv. La raison en est probablement qu'ils entendaient la langue pour être plus simple à apprendre. Un débutant pourrait essayer de mettre en œuvre une fonction d'échange lambda avec la valeur de la capture. C'est ce qui est communément appelé le principe de moindre surprise.
  • Pas sûr que c'est bon, lorsque tout le reste n'est pas const par défaut.
  • Szelei: ne Pas commencer un argument, mais à mon humble avis, le concept de "facile à apprendre" n'a pas sa place dans le langage C++, en particulier dans les temps modernes. De Toute Façon 😛
  • Bjarne lui-même l'a affirmé dans parler il y a deux ans. Je ne dis pas que C++ est facile à apprendre (ni celui de C++0x est), mais ce et les références rvalue les deux semblent viser le moins surprise de principe.
  • Szelei, juste par curiosité, comment est-référence rvalue "le moins surprenant"?
  • Parce que l'utilisation de références rvalue vous pouvez transmettre des valeurs temporaires à des fonctions qui s'attendent références (qui est, les références rvalue). Avec seulement lvalue refs vous ne pouvez pas. Cela, bien sûr, repose sur la personne qui a écrit cette fonction en particulier (et à être sensible, ils écrivent une avec deux r et lvalue de surcharge). Une meilleure façon de phrase, c'est que les références rvalue autoriser les responsables de l'implémentation de l'API pour écrire moins surprenant, le code de l'API de l'utilisateur (c'est pourquoi je dis qu'il vise pour cela). Au moins c'est ma compréhension de la motivation à l'origine de ces choses.
  • "le point de l'ensemble de la capture-par-valeur est de permettre à l'utilisateur de modifier le temporaire" - Non, l'essentiel est que le lambda peut rester valable au-delà de la durée de vie de tout capturé variables. Si C++ lambdas seulement eu de la capture-par-ref, ils seraient inutilisables dans beaucoup trop de scénarios.

InformationsquelleAutor kizzx2 | 2011-03-31
  1. 213

    Il exige mutable parce que, par défaut, un objet de fonction devrait produire le même résultat à chaque fois qu'il appelle. C'est la différence entre un objet orienté en fonction et une fonction en utilisant une variable globale, efficace.

    • C'est un bon point. Je suis totalement d'accord. Dans C++0x, cependant, je n'arrive pas à voir comment la valeur par défaut permet de maintenir la ci-dessus. Considérez que je suis sur la fin de réception de la lambda, par exemple, je suis void f(const std::function<int(int)> g). Comment suis-je assuré que g est en fait referentially transparent? gs'fournisseur pourrait avoir utilisé mutable de toute façon. Donc je ne sais pas. D'autre part, si la valeur par défaut est non-const, et les gens doivent ajouter const au lieu de mutable à des objets de fonction, le compilateur peut respecter la const std::function<int(int)> partie et maintenant f peut supposer que g est const, non?
    • Cette réponse est acceptée comme je pense que le plus étroitement répond à la pourquoi (comme dans la justification) de la partie.
    • En C++, rien n'est appliquée, seulement suggéré. Comme à l'habitude, si vous faites quelque chose de stupide (documenté exigence de transparence référentielle et puis passer de la non-referentially-transparent de la fonction), vous obtenez tout ce qui vient à vous.
    • À l'exception des objets de fonction ne pas produit le même résultat à chaque fois qu'ils sont appelés. Pas de fonctions inline dans toute autre langue moderne sont comme ça, et la valeur par défaut devrait être de faire comme le reste du monde. Laisser de C++ pour continuer à faire tout ce difficile et laid.
    • Suppose que vous devez avoir manqué tous ceux par exemple de la pure lambdas dans LINQ. Ce n'est pas appliquée; mais il est certainement recommandé que les fonctions (inc. les lambdas) être pur.
    • C'est tout simplement pas le cas dans les langages impératifs.
    • Cette réponse m'a ouvert les yeux. Auparavant, je pensais que dans ce cas lambda seulement se transforme en une copie pour le courant "exécuter".
    • Il est tout à fait vrai. La langue de paradigme n'est pas une excuse pour mauvaise conception.
    • Ce n'est pas bâclée de la conception. Certaines fonctions sont const (eg. gcc est attribut(const)), comme comparitors pour le tri, mais un grand nombre ne le sont pas, tels que la réalisation des gestionnaires pour des Api asynchrones. En général, elles sont loin de lui, car ils peuvent commencer une autre demande asynchrone ou même l'affichage de l'INTERFACE utilisateur. C'est un puissant paradigme, et il n'y a rien bâclée à ce sujet.
    • L'achèvement des gestionnaires pour des Api asynchrones n'ont pas besoin d'être logiquement non-const. L'asynchronicité ne fait pas de vous non-const, vous avez juste à y penser un peu différemment. Comme pour l'affichage de l'INTERFACE utilisateur, eh bien, cela devrait certainement pas être fait de façon complètement aléatoire en fonction des objets...
    • Votre commentaire m'a ouvert les yeux! 😀 je n'ai pas le vrai sens de cette réponse jusqu'à ce que j'ai lu votre commentaire.
    • votre commentaire me conduire à ZsoItSzatmari commentaire qui a ensuite ouvert les yeux! Ce qui veut probablement dire que cette réponse n'est pas très complet. Afin d'ajouter quelques précisions.
    • Oui, ça pourrait être utile.
    • Sérieusement, je ne comprends pas de quoi vous parlez. Par exemple, int i = 1; auto f = [i](){++i;}; f(); f(); f(); f(); Si ce n'est pas illégal, l'appel de quatre fois f() produira le même résultat, non? À MOINS que, le i dans le lambda et l'extérieur i sont le même objet. Donc, la question devient: est-ce la capture d'objet lambda et l'objet extérieur sont le même objet lors de la capture par valeur? Eh bien, je pense que c'PAS parce que c'est de la capture-par-valeur, au lieu de capture par référence. Alors, pourquoi ne pouvons-nous changer la capture de valeur lorsque nous utilisons la méthode de capture-par-valeur? Je pense que la réponse de Daniel, c'est mieux.
    • Je suis en désaccord avec le principe de base de cette réponse. C++ n'a pas de notion de "fonctions doivent toujours retourner la même valeur" nulle part ailleurs dans la langue. Comme un principe de conception, je suis d'accord c'est une bonne façon d'écrire une fonction, mais je ne pense pas qu'il retient l'eau comme le en raison de la norme de comportement.
    • Totalement d'accord avec @lonoclastBrigham et en désaccord avec cette réponse. Merci de ne pas dogmatiquement état que d'une meilleure pratique est la raison pour laquelle une décision technique dans la norme, à moins que vous ont fait partie de la discussion dans le comité des normes (et si oui, veuillez l'indiquer dans votre réponse).
    • J'avais lu les autres réponses pour comprendre ce que l'auteur de celui-ci a été pensée. Cette réponse est trop laconique, et seulement utile pour les personnes qui connaissent déjà ce qui se passe.
    • L'exemple donné dans la question serait de clarifier le point réel mieux via [=]() mutable {++n;}();, comme n=20 en fait de produire le même résultat à chaque fois, ce qui fait de la nécessité de mutable moins évident. Notez également le commentaire de @ZsoltSzatmari préciser plus avant.
    • "Un objet de fonction devrait produire le même résultat à chaque fois qu'il appelle." Non, Bien que cette déclaration peut être correct pour les langages de programmation fonctionnelle, et se trouve également être bon en programmation, C++ est multi-paradigme languge, pas de en exclusivité un langage fonctionnel. Par conséquent, on peut affirmer que les normes du comité n'a aucune autorité pour force un style de programmation fonctionnelle sur les programmeurs en C++.

    InformationsquelleAutor Puppy
  2. 97

    Votre code est presque équivalent à ceci:

    #include <iostream>

class unnamed1
{
    int& n;
public:
    unnamed1(int& N) : n(N) {}

    /* OK. Your this is const but you don't modify the "n" reference,
    but the value pointed by it. You wouldn't be able to modify a reference
    anyway even if your operator() was mutable. When you assign a reference
    it will always point to the same var.
    */
    void operator()() const {n = 10;}
};

class unnamed2
{
    int n;
public:
    unnamed2(int N) : n(N) {}

    /* OK. Your this pointer is not const (since your operator() is "mutable" instead of const).
    So you can modify the "n" member. */
    void operator()() {n = 20;}
};

class unnamed3
{
    int n;
public:
    unnamed3(int N) : n(N) {}

    /* BAD. Your this is const so you can't modify the "n" member. */
    void operator()() const {n = 10;}
};

int main()
{
    int n;
    unnamed1 u1(n); u1();    //OK
    unnamed2 u2(n); u2();    //OK
    //unnamed3 u3(n); u3();  //Error
    std::cout << n << "\n";  //"10"
}

    De sorte que vous pourriez penser lambdas comme la génération d'une classe avec l'opérateur (), qui est par défaut à const sauf si vous dites que c'est mutable.

    Vous pouvez aussi penser à toutes les variables capturées à l'intérieur de [] (explicitement ou implicitement) en tant que membres de cette classe: des copies des objets pour [=] ou références aux objets pour [&]. Ils sont initialisés lorsque vous déclarez vos lambda comme si il y avait un caché constructeur.

    • Alors qu'une belle explication de ce un const ou mutable lambda pourrait ressembler si elles sont appliquées comme équivalent types définis par l'utilisateur, la question est (comme dans le titre et élaborée par les OP dans les commentaires) pourquoi const est la valeur par défaut, donc ce n'est pas la réponse.
    InformationsquelleAutor Daniel Munoz
  3. 35

    J'étais sous l'impression que le point de l'ensemble de la capture-par-valeur est de permettre à l'utilisateur de modifier le temporaire -- sinon, je suis presque toujours préférable d'utiliser la capture par référence, ne suis-je pas?

    La question est, est-ce "presque"? Une utilisation fréquente de cas semble être de retour ou de passer des lambdas:

    void registerCallback(std::function<void()> f) { /* ... */ }

void doSomething() {
  std::string name = receiveName();
  registerCallback([name]{ /* do something with name */ });
}

    Je pense que mutable n'est pas un cas de "presque". Je considère que "la capture par la valeur de" j'aime "de me permettre d'utiliser sa valeur après la capture d'entité meurt" plutôt que "permettez-moi de changer une copie de celui-ci". Mais peut-être que cela peut faire valoir.

    • Bon exemple. C'est un très bon cas d'utilisation pour l'utilisation de la capture par valeur. Mais pourquoi est-il par défaut pour const? Quel but est-il atteint? mutable semble hors de propos ici, quand const est pas la valeur par défaut dans "presque" (:P) tout le reste de la langue.
    • Je souhaite const a la valeur par défaut, au moins les gens seront contraints de considérer const-correctness :/
    • la recherche dans le lambda-papiers, il me semble qu'ils font défaut à const donc ils pourraient l'appeler si oui ou non le lambda objet const. Par exemple, ils pourraient passer à une fonction prenant un std::function<void()> const&. Pour permettre le lambda changer sa capturé des copies, dans les premières études les données membres de la fermeture ont été définis mutable en interne automatiquement. Maintenant que vous avez à mettre manuellement mutable dans l'expression lambda. Je n'ai pas trouvé une justification détaillée des si.
    • Voir open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2651.pdf pour plus de détails.
    • Beau papier. C'est drôle comment les const "Proposition" dans le papier a chuté d'une façon. C'est en fait la façon dont je m'y attendais (en ligne avec le reste de la langue, comme un const fonction membre) (comme les programmeurs en C++, cela ne nous dérange pas d'être taxé de type const -- c'est un fait de la vie). Mais mutable semble avoir émergé à la fin pour une raison quelconque.
    • À ce stade, pour moi, la "vraie" réponse/justification semble être: "ils n'ont pas de travail autour d'un détail d'implémentation" :/

    InformationsquelleAutor Johannes Schaub - litb
  4. 27

    FWIW, Herb Sutter, un membre bien connu du C++ comité de normalisation, fournit une réponse différente à cette question dans la Lambda Exactitude et de Problèmes d'ergonomie:

    Considérer cet homme de paille exemple, où le programmeur capte une variable locale par
    valeur et tente de modifier l'
    capturé valeur (qui est une variable de membre de la lambda objet):

    int val = 0;
auto x = [=](item e)            //look ma, [=] means explicit copy
            { use(e,++val); };  //error: count is const, need ‘mutable’
auto y = [val](item e)          //darnit, I really can’t get more explicit
            { use(e,++val); };  //same error: count is const, need ‘mutable’

    Cette fonctionnalité semble avoir été ajouté le souci de l'utilisateur
    pourriez ne pas réaliser qu'il a obtenu une copie, et en particulier depuis les lambdas
    sont copiable, il pourrait être la modification d'une lambda copie.

    Son rapport sur les raisons de ce qui devrait être changé en C++14. Il est court, bien écrit, la lecture vaut la peine si vous voulez savoir "ce qui est sur [membre du comité] esprit" en ce qui concerne cette fonctionnalité particulière.

    InformationsquelleAutor akim
  5. 14

    Voir ce projet, sous 5.1.2 [expr.prim.lambda], le sous-alinéa 5:

    La fermeture pour un type lambda-expression a un public inline appel de fonction de l'exploitant (13.5.4) dont les paramètres
    et le type de retour sont décrites par le lambda-expression du paramètre-déclaration de la clause et trailingreturn-
    type respectivement. Cet appel de fonction de l'opérateur est déclarée const (9.3.1) si et seulement si le lambdaexpression de l'
    paramètre déclaration de la clause n'est pas suivie par mutable.

    Modifier sur litb commentaire:
    Peut-être qu'ils ont pensé de la capture par valeur, de sorte qu'en dehors des changements de variables ne sont pas reflétés à l'intérieur de la lambda? Références fonctionner dans les deux sens, de sorte que c'est mon explication. Ne sais pas si c'est une bonne cependant.

    Modifier sur kizzx2 commentaire:
    La plupart du temps quand une lambda est utilisée comme un foncteur pour les algorithmes. La valeur par défaut constness lui permet d'être utilisé dans un environnement constant, tout comme normale constqualifiés fonctions peuvent être utilisées là, mais nonconstqualifiés peuvent pas. Peut-être ils ont juste pensé à le rendre plus intuitif pour ces cas, et qui sait ce qui se passe dans leur esprit. 🙂

    • C'est le standard, mais pourquoi ont-ils écrire de cette façon?
    • Mon explication est directement en vertu de cette citation. 🙂 Il se rapporte un peu à ce que litb dit à propos de la durée de vie de la capture d'objets, mais aussi va un peu plus loin.
    • Oh oui, j'ai manqué 😛 C'est aussi un autre bon explication pour une bonne utilisation de la capture-par-valeur. Mais pourquoi devrait-il être const par défaut? J'ai déjà eu une nouvelle copie, il semble étrange de ne pas le laisser me changer, surtout qu'il n'est pas quelque chose principalement de mal à ça -- ils veulent m'ajouter mutable.
    • Voir mon edit, peut-être que cela a un sens. 😐
    • Je crois qu'il y avait une tentative de créer un nouveau général de la fonction syntaxe de déclaration, vous cherchez un peu comme un nom de lambda. Il a également été supposé corriger d'autres problèmes en faisant tout const par défaut. Jamais achevé, mais les idées déteint sur le lambda définition.
    • Persson, si ceux sont de vrai, de ce qui est sorti de C++0x est vraiment un désordre total :/
    • Si l'on pouvait tout recommencer, nous aurions probablement var en tant que mot clé pour permettre le changement et la constante étant la valeur par défaut pour tout le reste. Maintenant, nous ne le faisons pas, alors nous avons à vivre avec ça. OMI, C++2011 est sorti assez bien, compte tenu de tout.

    InformationsquelleAutor Xeo
  6. 12

    Vous devez penser quel est le fermeture type de votre fonction Lambda. Chaque fois que vous déclarez une expression Lambda, le compilateur crée une fermeture du type, qui n'est rien moins qu'une nouvelle déclaration de classe avec des attributs (environnement où l'expression Lambda où déclarés) et l'appel de la fonction ::operator() mis en œuvre. Lorsque vous capturez une variable à l'aide de copie par valeur, le compilateur va créer un nouveau const attribut dans le type de fermeture, de sorte que vous ne pouvez pas la modifier à l'intérieur de l'expression Lambda parce que c'est une "lecture seule" attribut, c'est la raison pour laquelle ils appellent ça une "fermeture", parce que d'une certaine façon, vous fermez votre expression Lambda en copiant les variables de la haute portée dans le Lambda de la portée. Lorsque vous utilisez le mot-clé mutable, la capture d'entité est devenu un non-const attribut de votre type de fermeture. C'est ce qui provoque les changements fait dans la mutable variable capturée par valeur, pour ne pas être propagées à haut champ, mais garder l'intérieur de la dynamique Lambda.
    Toujours essayer d'imaginer la fermeture consécutive de type de votre expression Lambda, qui m'a beaucoup aidé, et j'espère que cela peut vous aider aussi.

    InformationsquelleAutor Tarantula
  7. 9

    J'étais sous l'impression que l'
    tout point de capture-par-valeur est de
    permettre à l'utilisateur de modifier le temporaire
    -- sinon, je suis presque toujours préférable d'utiliser la capture par référence, n'est-ce pas
    J'?

    n est pas temporaire. n est un membre de la lambda-la fonction de l'objet que vous créez avec l'expression lambda. L'attente par défaut est que l'appel de votre lambda ne pas modifier son état, il est donc const pour vous empêcher de modifier accidentellement n.

    • L'ensemble de la lambda objet est temporaire, ses membres ont également temporaire de la durée de vie.
    • Autant que je me souvienne, je faisais allusion à la question que quand quelqu'un dit "temporaire", je comprends qu'il signifie sans nom objet temporaire, dont le lambda est lui-même, mais ses membres ne le sont pas. Et aussi qu'à partir de "l'intérieur" de la lambda, il n'a pas vraiment d'importance si le lambda en lui-même est temporaire. Re-lecture de la question mais il semblerait que l'opération consistait simplement à dire le "n à l'intérieur de la lambda" quand il a dit "temporaire".
    InformationsquelleAutor Martin Ba
  8. 4

    Il y a maintenant une proposition visant à alléger la nécessité mutable en lambda déclarations: n3424

    • Toute information sur ce qui est venu de qui? Personnellement, je pense que c'est une mauvaise idée, étant donné que le nouveau "capture de l'arbitraire des expressions" gommera la plupart des points de douleur.
    • Ouais, il semble comme un changement pour le plaisir.
    • Mais pour être juste, je m'attends il y a probablement beaucoup de développeurs C++ qui ne savent pas que mutable est même un mot-clé en C++.
    InformationsquelleAutor usta
  9. 3

    Vous devez comprendre ce que la capture de moyens! elle capture pas d'argument en passant! regardons quelques exemples de code:

    int main()
{
    using namespace std;
    int x = 5;
    int y;
    auto lamb = [x]() {return x + 5; };

    y= lamb();
    cout << y<<","<< x << endl; //outputs 10,5
    x = 20;
    y = lamb();
    cout << y << "," << x << endl; //output 10,20

}

    Comme vous pouvez le voir, même si x a été modifié pour 20 le lambda est encore de retour 10 ( x est encore 5 à l'intérieur de la lambda)
    Changer x à l'intérieur de la lambda moyen de changer le lambda lui-même à chaque appel (le lambda est la mutation à chaque appel). Pour faire respecter l'exactitude de la norme introduit la mutable mot-clé. En spécifiant un lambda comme mutable vous dites que chaque appel à la lambda pourrait entraîner un changement dans la lambda lui-même. Voyons un autre exemple:

    int main()
{
    using namespace std;
    int x = 5;
    int y;
    auto lamb = [x]() mutable {return x++ + 5; };

    y= lamb();
    cout << y<<","<< x << endl; //outputs 10,5
    x = 20;
    y = lamb();
    cout << y << "," << x << endl; //outputs 11,20

}

    L'exemple ci-dessus montre qu'en faisant le lambda mutable, l'évolution x à l'intérieur de la lambda "mute" la lambda à chaque appel avec une nouvelle valeur de x qui n'a pas de chose à voir avec la valeur réelle de x dans la fonction principale

    InformationsquelleAutor Soulimane Mammar
  10. 0

    D'étendre Chiot réponse, lambda fonctions sont conçues pour être les fonctions pures. Cela signifie que chaque appel donné un unique jeu de données d'entrée retourne toujours le même résultat. Nous allons définir entrée comme l'ensemble de tous les arguments plus toutes les variables lorsque le lambda est appelé.

    Dans les fonctions pures de sortie ne dépend que de l'entrée et non pas sur certaines internes de l'état. Par conséquent, toute fonction lambda, si pure, n'a pas besoin de changer son état et est donc immuable.

    Lorsqu'un lambda capture par référence, l'écriture sur capturés variables est une contrainte sur le concept de fonction pure, parce que toute une pure fonction est de permettre le retour d'une sortie, même si le lambda n'est certainement pas muter, car l'écriture arrive à des variables externes. Même dans ce cas, une utilisation correcte implique que si le lambda est appelée avec la même entrée, la sortie sera la même à chaque fois, en dépit de ces effets secondaires sur par-ref variables. Ces effets secondaires sont juste des façons de revenir à l'entrée supplémentaire (par exemple, mise à jour d'un compteur) et pourraient être reformulés dans une fonction pure, par exemple le retour d'un n-uplet au lieu d'une valeur unique.

    InformationsquelleAutor Attersson