Discussion :

[yan]

Salut.
Maintenant, les lambda semblent plutôt bien supporté par les compilateurs (visual 2010, gcc 4.5, mingw 4.5,...). Je pense que plusieurs d'entre vous les ont tester voire adopté. Donc, voilà je voulais savoir ce que vous en pensez.

J'ai testé un peu cette semaine et je trouve cela très pratique.

QGraphicsView de Qt permet l'affiche d'un scenegraph2D. Cette classe propose une fonction appeler pour dessiner par dessus la scène. J'ai donc reimplementé cette fonction pour qu'il utilise un std::function. Avec les lambda, je peux très simplement fournir à la vue une nouvelle méthode pour dessiner.

Quand on fait une ihm, un composent est souvent composé d'autre composent plus spécialisé. j'ai créé une widget qui utilise des std::function pour le dessin et les actions souris. Ainsi avec quelques lambda, le composant spécialise très simplement ce sous composant à ses besoin. Par exemple juste pour afficher une information de manière graphique.

Au finale, je trouve que cela simplifie et éviter de créé une multitude de classe très spécialisé .On est très proche des ce que permet les inner classe de jave et C#.

Par contre, faut pas en abusé sinon le code deviens compréhensible.

[Matthieu Brucher]

Je trouve ça aussi génial
Malheureusement, tous les IDEs ne le supportent pas encore (par ex. CDT).

[Goten]

Je regrette plusieurs choses : quelles soient pas polymorphiques, qu'elles puissent pas être récursive. (enfin si on peut, mais il faut les nommé... donc bon c'est plus des lambda :€ ). Mais sinon ouai c'est quand même bien cool.
Sinon pour palier à tout ça y'a boost.phoenix (surtout avec la V3 ... )

[yan]

Je regrette plusieurs choses : quelles soient pas polymorphiques,

C'est à dire?

[Goten]

Elles peuvent pas être générique. (essaye d'utiliser une lambda 0x avec mpl::for_each :€ ). Elles devaient l'être (mot clef auto me semble) mais ça a été abandonné par manque de temps. C'est dommage.

[Klaim]

Je trouve ça genial aussi surtout parceque ça me permet de rééllement encapsuler mes classes ayant des conteneurs en membre quand je veux permettre à du code exterieur d'agir sur les objets contenus mais de manière "controllé". Des points d'extension clean.


En fait ça simplifie énormément de code, et on a pas peur d'utiliser des lambda par souci de performance, comme on pourrait avoir peur pour de nouvelles features qui ont l'air avancées : ça ne reste qu'une autre manière d'exprimer les fonctors!

Ah oui et du coup utiliser std::for_each() ou std::sort() ou std::find_if() devient un plaisir.

[Arzar]

C'est à dire?

C'est à dire qu'il n'est pas possible d'avoir une lambda correspondante à une fonction object ayant un operator() template.

Je trouve ça genial aussi surtout parceque ça me permet de rééllement encapsuler mes classes ayant des conteneurs en membre quand je veux permettre à du code exterieur d'agir sur les objets contenus mais de manière "controllé". Des points d'extension clean.

Intéressant ! Tu pourrais développer ? (avec un petit exemple) Car perso, je n'ai pas encore utilisé les lambdas autrement que sur des petits snippets pour m'amuser, donc pas encore sur de vrai projet et ça m'intéresse beaucoup de voir en quoi les lambdas pourraient influencer le design de plus haut niveau.

[yan]

@Arzar : 666 messages ça fait peur ^^

C'est à dire qu'il n'est pas possible d'avoir une lambda correspondante à une fonction object ayant un operator() template.

J'ai un peut de mal à comprendre. Car quand on écrit un lambda on connait le contexte non? et ce contexte pourrai être template (j'ai pas testé)? Sinon, c'est plus logique de faire un foncteur.

Pour boost.phoenix, je trouve cela intéressant mais j'ai l'impression que c'est limité. Par exemple, comment créer une variable locale dans une boucle ou un if? Y as pas trop de perte de performance. Il semble qu'avec boost.lambda on pouvais perdre presque 30%.

D’ailleurs quelqu'un à une idée du coût de l'utilisation des lambda?

[Goten]

@Arzar : 666 messages ça fait peur ^^


J'ai un peut de mal à comprendre. Car quand on écrit un lambda on connait le contexte non? et ce contexte pourrai être template (j'ai pas testé)? Sinon, c'est plus logique de faire un foncteur.

l'exemple le plus parlant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
#include <boost/mpl/for_each.hpp>
#include <boost/mpl/vector.hpp>
#include <typeinfo>
#include <iostream>
 
struct print_type
{
    template<typename T>
	void operator()(const T& t)
	{
	    std::cout << typeid(t).name() << '\n';
	}
};
 
int main(int argc, const char *argv[])
{
    typedef boost::mpl::vector<int,char,float> vec;
 
    boost::mpl::for_each<vec>(print_type());
 
    //boost::mpl::for_each<vec>([](auto t) { std::cout << typeid(t).name();});
    return 0;
}

Pour boost.phoenix, je trouve cela intéressant mais j'ai l'impression que c'est limité. Par exemple, comment créer une variable locale dans une boucle ou un if?

Y'a le mot clef "let".

Y as pas trop de perte de performance. Il semble qu'avec boost.lambda on pouvais perdre presque 30%.

D’ailleurs quelqu'un à une idée du coût de l'utilisation des lambda?

Avec phoenix tout est inliné en principe. Pareil avec les 0x donc les perfs sont vraiment bonne.

[JolyLoic]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
#include <boost/mpl/for_each.hpp>
#include <boost/mpl/vector.hpp>
#include <typeinfo>
#include <iostream>
 
struct print_type
{
    template<typename T>
	void operator()(const T& t)
	{
	    std::cout << typeid(t).name() << '\n';
	}
};
 
int main(int argc, const char *argv[])
{
    typedef boost::mpl::vector<int,char,float> vec;
 
    boost::mpl::for_each<vec>(print_type());
 
    //boost::mpl::for_each<vec>([](auto t) { std::cout << typeid(t).name();});
    return 0;
}

Quand je vois ça, je me dis que le template metaprogramming est vraiment un outil formidable pour résoudre des problèmes que l'on n'aurais jamais eu sans template metaprogramming

[Goten]

Je vois bien où tu veux en venir, et ... t'as pas tort. Mais d'un autre côté la TMP a plein d'applications et on est amené à résoudre ce genre de problème oui, avec d'autres outils de TMP. Moi je vois ça vraiment comme un language à part, enfin, un language dans le language.

Donc oui comme ça sur un forum, ça parait abscons et inutile, mais dans la pratique on peut être amené à résoudre ce genre de problèmatique. (mais je suis sur que je t'apprends rien).

[Klaim]

Intéressant ! Tu pourrais développer ? (avec un petit exemple) Car perso, je n'ai pas encore utilisé les lambdas autrement que sur des petits snippets pour m'amuser, donc pas encore sur de vrai projet et ça m'intéresse beaucoup de voir en quoi les lambdas pourraient influencer le design de plus haut niveau.

Par exemple, dans la class suivante, j'ai une partie d'implementation d'un Composite. Je veux que les classes enfant de celle-ci puissent appliquer des algorithmes aux instances "enfants" contenues.
Donc j'ai fourni une fonction membre protected qui permet d'appliquer un algorithme à tous les enfants, mais de manière "controllée".

http://code.google.com/p/radiant-las...eEntityGroup.h
http://code.google.com/p/radiant-las...ntityGroup.cpp

C'est simple a lire et à écrire, et une fois en place, c'est très très très facile à utiliser, dés le moment ou la syntaxe lambda est dispo.

La class enfant de GameEntityGroup n'a plus qu'a utiliser GameEntityGroup::for_each() pour manipuler les enfants (j'aurais pu aussi ajouter une fonction de rechechea mais j'en ai pas eu besoin - YAGNI ).

Note que ça serait plus efficace théoriquement si j'utilisais une fonction template avec le fonctor en paramettre, comme pour les implementations des algos STL. Là j'ai voulu faire simple et juste cacher l'implementation( ce que les templates nous pourrissent facilement).

Ce qu'il faut comprendre ici, comme avantage, c'est que :
1. je n'ai pas eu a exposer directement le conteneur à mes classes enfant, ce qui fait qu'on a largement moins de chances de se retrouver à un moment avec on conteneur chamboulé! Encapsulation maximale, avec points d'extension controlés.
2. les vérifications à l'accès de mes elements sont toujours les mêmes et centralisées de manière à ce qu'une correction dans le for_each corrige tous les algorithms qui en dépendent.
3. en soit, le for_each est ecrivable sans les lambda, mais la force des lambda est dans le fait que du coup on a pas besoni de faire des fonctors pour utiliser la fonction (voir update_children() et render_children() ).

(note : dans cet exemple le code est "naif", parceque c'est un prototype torché en moins d'une semaine de temps perso)
(note2: je pense que j'ai du utiliser les lambdas a d'autres endroit dans ce projet, ya qu'a chercher )

[JolyLoic]

Donc oui comme ça sur un forum, ça parait abscons et inutile, mais dans la pratique on peut être amené à résoudre ce genre de problèmatique. (mais je suis sur que je t'apprends rien).

Tout à fait

En fait, ma réaction venait du fait que dès qu'on parle des lambdas C++0x, la remarque qu'ils ne sont pas polymorphes arrive dans les 10s. C'est vrai. Et c'est une limitation dans certains cas. Il n'en reste pas moins que je suis persuadé que la grande majorité des utilisateurs (ceux qui éventuellement utilisent précautionneusement une bibliothèque à base de TMP en interne, mais n'en écriraient jamais une eux-même) n'aura pas besoin de lambdas polymorphes.

Alors que je pense que la même très grande majorité pourra utiliser simplement les lambdas tels qu'ils sont actuellement définis pour améliorer considérablement leur code. Des aspects complets de la STL sont quasi inutilisables sans les lambdas (tous les algorithmes avec prédicat), la programmation parallèle aura du mal à se démocratiser sans lambdas.

Lors de l'évolution du langage pour C++0x, deux voies de progrès étaient annoncées : Rendre le langage plus puissant à utiliser pour les experts, et rendre le langage plus simple à utiliser par les gens normaux. Et les deux me semblent très importantes. Tels que définis aujourd'hui, les lambdas me semblent très bien répondre à la seconde problématique. Et les lambda polymorphes (proposés au début) faisaient se poser tellement de questions aux implémenteurs que finalement le choix se résumait à lambdas monomorphes ou pas de lambdas du tout. Dans ce contexte, je suis content que l'on ait les lambdas monomorphes, pour la suite, on verra.

Ce dont j'ai peur, c'est que quelqu'un non expert qui se dise "tiens, ya des lambdas maintenant, voyons comment ça marche" tombe tout de suite sur des avis d'experts respectés dont la première phrase est : "ils ne sont pas polymorphes" et que cette personne se dise "ah bon, ça ne marche pas bien alors ? je sais pas trop ce que ça veut dire, mais bon, le polymorphisme, c'est un truc bien, donc si les lambdas n'ont pas ça, c'est probablement pas très utilisable ? Je vais m'en passer...". C'est un peu voir un verre à 5% vide, là ou j'aimerais promouvoir le verre à 95% plein

[Goten]

Tout à fait
En fait, ma réaction venait du fait que dès qu'on parle des lambdas C++0x, la remarque qu'ils ne sont pas polymorphes arrive dans les 10s.

Sa me semble familier cette situation, on a déjà eu cette conversation il me semble .
Néanmoins, c'est vrai ça tiens plus du réflexe qu'autre chose (je suis assez attaché à phoenix pour tout dire, surtout la V3), mais dans ce cas précis le topic était assez ouvert et orienté clairement sur la discussion autour des lambdas. (au contraire d'un topic sur "comment ça marche les lambdas") donc pour le coup ça me semble opportun de le mentionner.

C'est vrai. Et c'est une limitation dans certains cas. Il n'en reste pas moins que je suis persuadé que la grande majorité des utilisateurs (ceux qui éventuellement utilisent précautionneusement une bibliothèque à base de TMP en interne, mais n'en écriraient jamais une eux-même) n'aura pas besoin de lambdas polymorphes.

Tout à fait d'accord.

[...] avis d'experts respectés [...]

<sarcasm>
Merci, ça me touche, mais fallait pas je suis gêné maintenant.
</sarcasm>
(les balises cassent le côté drôle de la chose, mais sinon on pourrait me traiter de pédant et ça serait dommage... :' )

Ce dont j'ai peur, c'est que quelqu'un non expert qui se dise "tiens, ya des lambdas maintenant, voyons comment ça marche" tombe tout de suite sur des avis d'experts respectés dont la première phrase est : "ils ne sont pas polymorphes" et que cette personne se dise "ah bon, ça ne marche pas bien alors ? je sais pas trop ce que ça veut dire, mais bon, le polymorphisme, c'est un truc bien, donc si les lambdas n'ont pas ça, c'est probablement pas très utilisable ? Je vais m'en passer...". C'est un peu voir un verre à 5% vide, là ou j'aimerais promouvoir le verre à 95% plein

Encore une fois, ton point de vue est tout à fait valide et tes craintes sont (je pense) justifiées. J'y réfléchirais donc à deux fois la prochaine fois qu'un topic apparaitra sur les lambda 0x.

Néanmoins je tiens à te faire remarquer que j'ai soulevé un autre point : le fait qu'elles ne puissent pas être récursive. Bizarrement après le basique hello world c'est la deuxième chose que j'ai voulu faire (une lambda factorielle), sans succés bien entendu. Enfin si, en la nommant on peut s'en sortir, mais on perd l'intérêt des lambda ...
Mais là encore, on pourrait m'objecter (à raison je pense), que c'est moi qui ai trop tendance à chercher à faire pour faire, plutôt que d'avoir une application réelle. (mon côté universitaire ça :' )

[yan]

mais dans ce cas précis le topic était assez ouvert et orienté clairement sur la discussion autour des lambdas. (au contraire d'un topic sur "comment ça marche les lambdas") donc pour le coup ça me semble opportun de le mentionner.

C'est aussi le but de ce topic.

• Regrouper les premières expériences pour voir les points fort et faible des lambdas.
• Comprendre le potentiel.
• Eviter sa mauvaise utilisation.
• Apprendre.

D’après les réponses, je ne fait pas encore trop n’importe quoi avec. Ça me rassure.

Ce que je trouve intéressant avec std::function et les lambda on peux très simplement rendre les fonctionnalités d'une classe dynamic.
Par exemple, j'ai une classe qui me permet de visualiser différent type d'image (char, short, float, complex, rgb ,...). En fonction du type d'image reçus, je modifier certaine fonction qui permettrons à la classe de l'afficher. Ceci me permet de supprimer les if pour faire ceci ou cela en fonction de l'image reçus.

[Joel F]

Pour rebondir sur Goten & Loic. Personnelement , ca serait appelé 'anonymous function' et pas lambda, j'aurais jamais ticquer sur l'absence de recursivité et de polymorphisme.

Lambda fonction ca represente un objet mathématique bien precis et quant tu sais ce que sais, tu t'attends à certaines propriétés.

Ca fait partie des choses ou j'aurais bien voulu savoir comment faire parti du comité de standardisation pour emettre une reserve

[yan]

pour emettre une reserve

Une reserve sur quoi? les lambda?

[Matthieu Brucher]

Sur le nom donné.

En même temps, elles ont bien plus de propriétés que d'autres lambdas, comme celles de Python par ex qui s'appellent aussi lambda et qui sont limitées à des fonctions pures.

[Goten]

Une reserve sur quoi? les lambda?

Oui, ce à quoi fait référence Joel, c'est le lambda calculus (cf les travaux de M. Church), qui implique bien plus que des fonctions non-nommés.