Discussion :

[Bktero]

Bonjour

Je suis de la team "const autant que possible". Donc, dès que je vois une déclaration de variable à laquelle je peux ajouter const, je le fais.

Je fais une exception à cette règle : quand je stocke une lambda expression, je n'ajoute jamais const. Je fais auto foo = []() {}; et non const auto foo = []() {};.

Pourtant, en suivant la logique "const autant que possible", je devrais aussi utiliser const dans cette situation.

Comment faites-vous ? auto ou const auto pour les lambdas ? Pourquoi ?

PS : pour celles et ceux qui ne savent pas, on ne peut changer la valeur de la variable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int main() {
    auto f = []() {};
    f = []() {};
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<source>:3:7: error: no viable overloaded '='
    3 |     f = []() {};
      |     ~ ^ ~~~~~~~
<source>:2:14: note: candidate function (the implicit copy assignment operator) not viable: no known conversion from '(lambda at <source>:3:9)' to 'const (lambda at <source>:2:14)' for 1st argument
    2 |     auto f = []() {};
      |              ^
1 error generated.
Compiler returned: 1

EDIT : on peut produire un exemple où le typage correspond et où l'affectation est quand même rejetée (de toute façon, c'est pas un cas très utile) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int main() {
    auto f = []() {};
    auto g = f;
    f = g;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<source>:4:6: error: object of type '(lambda at <source>:2:14)' cannot be assigned because its copy assignment operator is implicitly deleted
    4 |         f = g;
      |           ^
<source>:2:14: note: lambda expression begins here
    2 |     auto f = []() {};
      |              ^

[ternel]

A priori je suis d'accord qu'il faudrait un const.

Cela dit, j'ai une réserve sur ton exemple.
Chaque lambda est d'un type unique. Du coup, dans ton exemple, tu essaies d'affecter deux types non compatibles.

Par contre, j'ai passé dix minutes à trouver un contre exemple, et j'arrive quand même à un refus.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#include <iostream>
int main() {
    int state = 0;
    auto f = [state]() mutable { return ++state; };
    auto backup = f;
    auto g = f;
    for (int i = 0; i < 10; ++i) std::cout << f() << ' ';
    for (int i = 0; i < 10; ++i) std::cout << g() << ' ';
    f = backup;
    return 0;
}

Avec GCC, en C++17, ce code-ci échoue avec le message suivant, mais uniquement à la ligne f = backup;.

error: use of deleted function ‘main()::<lambda()>& main()::<lambda()>::operator=(const main()::<lambda()>&)’

[Astraya]

Hello,
Cela fait longtemps que je ne suis pas venu ici !
Ça n'a pas trop de sens d'avoir un lambda const car par defaut l'operator()est const.

Une lambda ce n'est rien de plus que du sucre syntaxique d'un foncteur, donc si f est const il ne peux modifier son état dans l'operator(), donc ne peut modifier ces variables internes comme toutes méthodes const d'une classe, or l'operator() étant const par défaut, this est const par défaut dans l'operator().

Cela n'apporte rien.

[Bktero]

Mon seul bon argument pour ne pas ajouter const est effectivement que ça ne sert à rien, la variable étant en quelque sorte "implicitement const". L'autre argument que je peux avoir c'est "ça met plus en évidence la lambda", mais il me semble un peu léger. J'ai l'impression que personne n'a de bons arguments pour ne pas mettre const

Les raisons techniques du langage derrière ne sont pas vraiment intéressantes dans un document de "code style", et ce n'est d'ailleurs pas le sujet ici

[ternel]

J'ai l'impression que personne n'a de bons arguments pour ne pas mettre const

Ce qui est en soit une bonne raison pour le mettre.

Je préfère être explicite, et je cite les C++ Core Guidelines:
I.1: Make interfaces explicit
ES.25: Declare an object const or constexpr unless you want to modify its value later on

[gabriel21]

Pourquoi alourdir le code si de toutes les façons nous ne pouvons pas modifier un lambda ?

Est-il utile d'expliciter un état qui ne peut être intrinsèquement autre ?
La règle du const tient parce qu'une variable peut être modifiée ou pas. Cela permet d'expliciter la volonté du programmeur voir du modeleur dans les cas où plusieurs options sont possible. J'ai tendance à mettre le const dans les modèle UML.

[koala01]

Salut,

Ce qui est en soit une bonne raison pour le mettre.

Je préfère être explicite, et je cite les C++ Core Guidelines:
I.1: Make interfaces explicit
ES.25: Declare an object const or constexpr unless you want to modify its value later on

Et tu as tout à fait raison avec ce point. Il faut juste se mettre d'accord sur les termes que l'on utilise...

Car la ligne directrice ES25 parle d'objets, et non d'expressions. C'est donc qu'il est utile de faire la distinction entre les expressions qui représentent effectivement objets -- comme les données et les constantes -- et les expressions qui ne représentent pas des objets, comme les fonctions.

Or, les expressions lambda sont plus proche des fonctions que des objets, ce qui fait qu'il n'y a finalement que peut de raison de les déclarer constantes.

Tu pourras, bien sur, me dire que les fonction peuvent renvoyer une valeur constante, et que l'on peut même trouver facilement une situation dans laquelle c'est effectivement la fonction qui est déclarée constante (lorsque l'on a affaire à une fonction membre).

Dans le premier cas, cela ne change rien, vu que toutes les fonctions ne renvoient pas forcément une donnée, et que la constance de la donnée renvoyée n'a -- en définitive -- absolument rien à voir avec le comportement de la fonction en elle-même.

Dans le deuxième cas (les fonctions membres constantes), la constance n'a pour but que d'indiquer le fait que la donnée à partir de laquel la fonction sera appelée ne sera pas modifiée. Ce qui nous place bel et bien sur une constance d'objet...

Lorsque tu assignes une expression lambda à f (ou à g, ou à tout ce que tu peux vouloir) sous la forme de f =[](){}, tu crées d'avantage un alias sur une expression (f étant au final une expression) qu'un objet (une donnée dont le type serait l'expression elle-même), le mot clé auto étant là pour représenter le retour de l'expression dans le cas où l'expression serait destinée à renvoyer une valeur.

Au final, nous pourrions dire que "oui, il faut rendre tous les objets que l'on peut constants, à moins d'avoir de bonnes raisons de croire qu'ils devront être modifiés", dans le respect de la ES25; cependant, il faut se rendre compte que seules les données sont susceptibles d'être considérées comme des objets