de l'int�r�t des lambda

Bonsoir,

loin de moi de nourrir un bon gros troll poilu, mais plus je lis des articles sur les lambda, plus je constate que c'est un truc inutile.

je m'explique, par exemple � la lecture de http://herbsutter.com/elements-of-modern-c-style/

prenons ce morceau de code auto i = find_if( begin(v), end(v), [=](int i) { return i > x && i < y; } );quel est l�int�r�t de de mettre un lambda, on peut supposer que ce find_if ne risque pas d'�tre tout seul dans tout le code, avec autant de r�p�tition du lambda, donc tr�s mauvais niveau r�utilisation.

apr�s on peut toujours faire comme dans l'exemple de 3DArchi (http://www.developpez.net/forums/d1160181/c-cpp/cpp/langage/fonction-lambda-parametre-fonction/)

Code:

---

1 2 3 4 5 6

auto lambda = [](int i1, int i2) { return i1+i2; } ;

---

et dans ce cas, quel est l'int�r�t par rapport � un foncteur je dirai "traditionnel" ? si quelqu'un a une petite explication ...

Bonsoir,

Tu ne trouves pas que c'est quand m�me bien plus simple (aussi bien � �crire qu'� faire �voluer) que de devoir utiliser une classe (et donc lui trouver un nom) avec une fonction membre et un constructeur si l'on doit faire une capture ?

bah comme �a, non, je ne trouve pas �a plus simple (avis personnel, pas de justification), de plus que �a soit le foncteur et le lambda, il faut un nom de toute fa�on, de ce cot� l� �a change pas grand chose.

apr�s je vois un autre inconv�nient qui vient de surgir, le foncteur, tu n'as pas � en instancier une ... instance; le lambda, soit tu en as un en local, qui risque d'amener une duplication t�t ou tard, soit en global ...

apr�s si c'est juste du sucre syntaxique, �a remue, selon moi, beaucoup d'air pour pas grand chose.

Avec un foncteur tu as aussi une instance.

Pour les lambda si tu l'utilises juste une fois tu n'as pas besoin de lui donner un nom.

Ecrit un foncteur prenant en capture un seul �l�ment, et apr�s ajoute un deuxi�me �l�ment en capture. Maintenant fait pareil avec une lambda, tu devrais voir que c'est quand m�me plus simple.

Oui globalement ce n'est que du sucre syntaxique comme beaucoup d'utilisation d'�l�ments de syntaxe ajout�s au C++11. Peut-�tre que ceux qui font des maths th�oriques y verront des choses plus fondamentales (mais l� je peux pas t'aider ^^).

peut �tre bien que oui, peut �tre bien que non, je testerai �a plus tard dans la journ�e.

entre temps je suis tomb� la dessus : http://channel9.msdn.com/Events/PDC/PDC10/FT13
et ben m�me apr�s �a, je cherche encore le truc.

ps: j'ai peut �tre compris quelque chose d'int�ressant dans la vid�o, mais la syntaxe r�sultante est tellement tordu que �a en perd tout l'int�r�t.

C'est vrai que pour les lambda, il y a un probl�me de duplication de code. En m�me temps, le code dupliqu� sera en g�n�ral extr�mement simple.

De plus, les lambda ont la possibilit� de travailler sur une capture (en plus des param�tres). Et je soup�onne que nous allons voir apparaitre du code qui s'auto-modifie, de cette mani�re :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

auto lambda1 = [](int i1, int i2) -> void { ... } auto lambda2 = [](int i1, int i2) -> void{ ... } // même prototype   struct polylambda { std::function<void(int,int)> process; };   int main() { polylambda pl; if (std::string(av[1]) == "1") pl.process = lambda1; else pl.process = lambda2; pl.process(atoi(av[2]), atoi(av[3])); }

---

Citation:

---

Envoy� par Emmanuel Deloget

Et je soup�onne que nous allons voir apparaitre du code qui s'auto-modifie, de cette mani�re :

//code

---

Cette remarque me rends tout � fait perplexe. En quoi est-ce que le code pr�sent� en exemple s'auto-modifie ? En quoi est-ce qu'il est diff�rent d'une solution � base de pointeur de fonction qui est "apparue" il y a plus de trente ans. :aie:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void lambda1(int i1, int i2) { printf("lambda1\n");} void lambda2(int i1, int i2) { printf("lambda2\n"); }   typedef void(*FuncVoidIntInt)(int, int);   struct polylambda { FuncVoidIntInt process; };   int main(int * argc, char* argv[]) { polylambda pl; if (strcmp(argv[1], "1") == 0) pl.process = &lambda1; else pl.process = &lambda2; pl.process(atoi(argv[2]), atoi(argv[3])); }

---

J'ai l'impression que l'int�r�t des lambda-fonctions par rapport aux foncteurs est du m�me ordre que celui des op�rateurs ternaires cond?vraie:fausse par rapport aux blocs if/else : un petit artifice de programmation qui peut faciliter la lecture du code, d�s lors qu'on l'utilise sur des instructions raisonnablement courtes, triviales et peu susceptibles d'�voluer. Non ?

Citation:

---

Envoy� par Arzar

Cette remarque me rends tout � fait perplexe. En quoi est-ce que le code pr�sent� en exemple s'auto-modifie ? En quoi est-ce qu'il est diff�rent d'une solution � base de pointeur de fonction qui est "apparue" il y a plus de trente ans. :aie:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void lambda1(int i1, int i2) { printf("lambda1\n");} void lambda2(int i1, int i2) { printf("lambda2\n"); }   typedef void(*FuncVoidIntInt)(int, int);   struct polylambda { FuncVoidIntInt process; };   int main(int * argc, char* argv[]) { polylambda pl; if (strcmp(argv[1], "1") == 0) pl.process = &lambda1; else pl.process = &lambda2; pl.process(atoi(argv[2]), atoi(argv[3])); }

---

---

Pareil en assembleur. Je me demande pourquoi ils ont invent� le C et les pointeurs sur fonction. :)

Bien �videmment, le principe est exactement le m�me (� trois poils de taureau pr�s : le pointeur de fonction implique une redirection suppl�mentaire qui n'est pas n�cessairement impliqu�e par la lambda ; la lambda peut capturer une partie du contexte dans laquelle elle est cr��e).

Ceci dit, je me suis mal exprim� ; mon commentaire voulait seulement souligner que l'int�gration des lambda dans C++11 peut ammener au d�veloppement d'un nouveau paradigme de programmation en C++, qui se basera probablement sur un mix (m�ta-prog + lambda), et qui devrait ammener un vent nouveau dans ce domaine.

Bien �videmment, l'exemple que j'ai donn� est simpliste et de peu d'int�r�t. Mais pensez � un syst�me d'�coute d'�v�nements par exemple, ou la lambda joue le r�le d'une fonction de traduction d'un format de message sp�cifique vers un format utilisable par un handler sp�cifique (par exemple, les param�tres des messages WM_MOUSEMOVE -> (btnstate + point<int>)).

Le probl�me n'est pas de savoir si quelque chose existait avant ou pas (y-a-t-il des choses que vous pouvez faire avec le nouveau standard C++ et qui �tait strictement impossible � faire avec l'ancien ? Qu'apporte C++ par rapport � Fortran 66 en termes de possibilit�s ? Strictement rien : tout programme �crit en C++11 peut �tre �crit en F66 ; par contre, l'�crire en F66 demandera 10 fois plus de temps et 10 fois plus d'�nergie). Il s'agit de savoir si la fonctionnalit� apporte un plus en terme d'expressivit�, de s�curit� d'utilisation et de simplicit� de mise en oeuvre.

Citation:

---

Envoy� par cob59

un petit artifice de programmation qui peut faciliter la lecture du code, d�s lors qu'on l'utilise sur des instructions raisonnablement courtes, triviales et peu susceptibles d'�voluer. Non ?

---

Tr�s juste pour une simple raison. Si ce n'est pas trivial, c'est difficile de le tester � part, contrairement � un foncteur...

@Emmanuel Deloget : je comprends bien ton point de vu, mais dans le cas du lambda, je ne vois pas de situation o� son �criture facilite la vie du programmeur, et pire ni celle du relecteur.
dans la vid�o que j'ai mis le lien un peu plus haut, l'auteur encapsule le corps d'un do...while dans un lambda, et �a devient illisible, et la finalit� pas forc�ment �vidente � saisir.
�a s'oppose par exemple � auto : la finalit� et la compr�hension est imm�diate, apr�s la l�gitimit� �a se discute, mais au moins on comprend sa pr�sence.

par contre j'ai une question � propos du point que tu soulignes sur la redirection suppl�mentaire; �a ferait pas plus partie des possibilit�s du compilateur � optimiser du code que sur les fonctionnalit�s du lambda?

Les personnes qui ne voient pas l'interet des lambda (ou de tout autre features) devraient tout simplement les mettre en pratique dans un projet, voir dans quels cas ils sont utiles.


Parcequ'ils sont tr�s utiles.


D'abord, supposer que les algorithmes des lambdas vont �tre r�utilis�s souvent est tout simplement faux. La plupart du temps, c'est la fonction dans laquelle on a utilis� l'algorithme qui est r�utilis�, pas le foncteur/lambda utilis� dans l'algorithme.
Cela dit, c'est par ex�p�rience que je dis �a.

Ensuite, rien n'empeche d'utilser un foncteur quand on en a besoin. Le fait est que c'est assez rare, d'o� la simplification qu'apporte le lambda.

Il y a des tonnes d'autres avantages aux lambda, mais c'est le plus �vident dans la pratique (qu'il faut prendre avant d'avoir une id�e clair de ce genre de feature) surtout si on utilise les algorithmes stl souvent ou qu'on en �crit soit m�me.

Car oui l'un des gros avantages est que lorsqu'on �crit un algorithme, on a beaucoup moins peur de demander un foncteur � l'utilisateur. Apr�s tout, chaque fois qu'on �crit un algorithme ou m�me une fonction membre qui aurait interet a demadner un "visiteur", on peut avoir tendance � �viter de demander un foncteur parceque c'est tr�s tr�s tr�s chiant a �crire pour l'utilisateur (alors que la plupart des foncteurs qu'on �crit pourraient se r�sumer a une fonction libre d'une ligne - mais on perds des avantages non n�gligeables ).

Maintenant qu'on a les lambda, c'est simple, on a aucune mauvaise raison de ne pas demander une fonction comme argument d'un algorithme quand le design de celui-ci parait �vident.


Pour avoir tent� l'exp�rience (avec mod�ration!) sur plusieurs projets, �a "lib�re" incroyablement l'expression du code.

Commencons par l'utilisation la plus simple : direct pour un algorithme sans capture.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

template<class F> void bar(F f) { f(0); }   struct C { void foo() const { bar([](int i){}); } };   struct D { struct F { void operator()(int i) const { } };   void foo() const { bar(F()); } };

---

Personnelement j'aurais tendance � pr�f�rer la version lambda tant que le foncteur utilis� est simple, et c'est souvent le cas AMA. Sinon en effet un foncteur est peut-�tre plus lisible, ou du moins totalement personnel.

Maintenant un exemple avec capture o� l'utilisation est localis�e � une seule fonction (�ventuellement plusieurs fois) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

struct A { void foo(int& p1, int& p2) const { auto l = [&p1/*ici*/](int i){}; l(0); l(1); } };   struct B { struct F { int& rp1; /*ici*/ F(int& rp1/*ici*/) : rp1(rp1) /*ici*/ { } void operator()(int i) { } };   void foo(int& p1, int& p2) const { F f(p1/*ici*/); f(0); f(1); } };

---

Les commentaires /*ici*/ signale les endroit � modifier si l'on a besoin de plus d'�l�ments dans la capture : 1 vs 4, j'aurais tendance � conclure que les lambda permettent une meilleur �volutivit� du code.

Pour l'histoire "simplifier la vie du lecteur" c'est juste qu'une �volution du langage va n�cessairement donner du mal aux utilisateurs pour lire du nouveau code dans un premier temps (comme apprendre un nouveaux langage), ceci dit on a probablement le m�me effet quand on utilise pour la premi�re fois certaines biblioth�ques, celle de m�ta-prog par exemple.

Il y a plusieurs probl�mes avec ce que tu pr�sentes. D'abord, perso je vois rarement du code qui construit un lambda et le r�utilise direct, donc c'est pas vraiment d�monstratif.

En plus tes lambda son vides alors �a donne pas une tr�s bonne id�e de ce que �a donne dans du vrai code.

Au del� de �a, tu te compliques la vie avec le second exemple : si tu captures avec [&] le compilateur ne va prendre (par r�f�rence) unique que ce que tu utilises dans la lambda et qui est dispo dans le scope au dessus de la lambda. Pareil pour la capture par copie.

Voici un exemple de code r��l (et un peu bordelique � vrai dire :aie: , mais bon) o� j'ai beaucoup utilis� de lambda.

Note : j'ai du mettre les for_each dans des fonctions s�par�es parcequ'ils sont accessibles depuis l'ext�rieur de la classe et que c'est le seul moyen de parcourir le contenu de la classe, ce qui �vite d'avoir a exposer un conteneur oui ce genre de joyeuset�.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

bool Project::save() { using namespace boost::property_tree;   // fill it with properties that needs to be saved ptree infos;   infos.put( "project.name", name() );   foreach_sequence( [&]( const Sequence& sequence ) { infos.add( "project.sequences.sequence", sequence.location().generic_string() ); });   foreach_edition( [&]( const EditionSession& edition_session ) { infos.add( "project.edition.session", edition_session.id() ); });   if( m_selected_session ) infos.add( "project.edition.selected", m_selected_session->id() );   // TODO : add other informations here // TODO : manage errors differently   try { namespace bfs = boost::filesystem; const auto directory_path = m_location.parent_path();   // make sure the directory is available if( !bfs::is_directory( directory_path ) ) { bfs::create_directories( directory_path ); }   bfs::ofstream filestream( m_location ); write_xml( filestream, infos ); } catch( const boost::exception& e ) { UTILCPP_LOG_ERROR << boost::diagnostic_information(e); return false; }   std::for_each( m_sequences.begin(), m_sequences.end(), [&]( std::unique_ptr<Sequence>& sequence ) { sequence->save(); });   std::for_each( m_edit_sessions.begin(), m_edit_sessions.end(), [&]( std::unique_ptr<EditionSession>& edition_session ) { const auto& file_path = directory_path() / path::EDITION_SESSION_FILE( edition_session->id() ); edition_session->save( file_path ); });   return true; }   void Project::foreach_sequence( std::function< void ( const Sequence& sequence )> func ) const { std::for_each( m_sequences.begin(), m_sequences.end(), [&]( const std::unique_ptr<Sequence>& a_sequence ){ func(*a_sequence); } ); }   void Project::foreach_edition( std::function< void ( const EditionSession& edition_session )> func ) const { std::for_each( m_edit_sessions.begin(), m_edit_sessions.end(), [&]( const std::unique_ptr<EditionSession>& a_session ){ func(*a_session); } ); }

---

Le truc qui m'ennuie avec les lambda actuelles (comme beaucoup le d�plorent) c'est qu'ils ne detectent pas automatiquement le type des attributs quand on les passe � un algorithme. Les gens du standard disent que c'est possible mais que �a sera pour une autre version.


EDIT : je me rends compte que ce code a bsion d'un poil de refactoring parcequ'il a �t� fait en plusieurs fois et �a se sent :aie:

Citation:

---

Envoy� par Klaim

Il y a plusieurs probl�mes avec ce que tu pr�sentes. D'abord, perso je vois rarement du code qui construit un lambda et le r�utilise direct, donc c'est pas vraiment d�monstratif.

---

Ca s'addresse � quel exemple ? Le premier avec la fonction bar ou le second avec les appels direct � f et l ? Dans les deux cas le but n'est pas de montrer une utilisation r�el des lambda mais de voir les diff�rences entre lambda et foncteur, or le passage et l'utilisation dans une fonction de l'un ou de l'autre sont identiques.

Dans le premier exemple j'ai introduit une fonction bar pour illuster la construction de la lambda du foncteur directement � l'endroit d'utilisation, dans le second cas l'op sugg�rait qu'une lambda / un foncteur peut �tre utiliser plusieurs fois, c'est ce que j'ai fait (j'aurais pu fait 2 fonction bar1 et bar2 et les utilisers une fois chaque une avec la lambda / le foncteur, mais je ne pense pas que ca apporte grand chose � la comparaison des deux syntaxes).

Citation:

---

Envoy� par Klaim

En plus tes lambda son vides alors �a donne pas une tr�s bonne id�e de ce que �a donne dans du vrai code.

---

Je vois pas trop ce que ca change, remplis les {} de la lambda ou de l'op�rateur () si tu y tiens :ccool: . Cependant j'ai quand m�me fait la remarque qu'avec du code "long/compliqu�" l'utilisation d'un foncteur serait peut-�tre plus lisible.

L'id�e �tait ici de comparer les deux syntaxes, remplir les {} va augmenter les deux codes d'exactement la m�me mani�re (� quelques noms d'itentifieurs pr�s), ca n'apporte rien � la comparaison.

Citation:

---

Envoy� par Klaim

Au del� de �a, tu te compliques la vie avec le second exemple : si tu captures avec [&] le compilateur ne va prendre (par r�f�rence) unique que ce que tu utilises dans la lambda et qui est dispo dans le scope au dessus de la lambda. Pareil pour la capture par copie.

---

Ca change pas la conclusion, les expliciter permet (AMA) de rendre plus clair le parall�le lambda/foncteur, mais c'est qu'un avis.

Edit: Mon code (contrairement au tien) n'avait pas pour but de montrer une utilisation r�el des lambda, mais de comparer les syntaxes lambda/foncteur. A contrario le tien pr�sente une utilisation des lambdas, mais ne permet pas cette comparaison de mani�re direct :ccool:

Citation:

---

Envoy� par Klaim

Le truc qui m'ennuie avec les lambda actuelles (comme beaucoup le d�plorent) c'est qu'ils ne detectent pas automatiquement le type des attributs quand on les passe � un algorithme. Les gens du standard disent que c'est possible mais que �a sera pour une autre version.

---

Polymorphiques ? Si je me trompe pas ca a �t� refus� car incompatible avec l'ajout de la notion de Concept propos� � l'�poque. Enfin, on a toujours boost::phoenix pour ca en attendant 8-)

Citation:

---

Envoy� par Flob90

Polymorphiques ? Si je me trompe pas ca a �t� refus� car incompatible avec l'ajout de la notion de Concept propos� � l'�poque. Enfin, on a toujours boost::phoenix pour ca en attendant 8-)

---

Pas exactement, mais c'est li�, en gros il faudrait une autre syntaxe et ils avaient pas le temps de travailler dessus alors ils ont dit "plus tard". Mais ya d�j� pas mal de suggestions pour utiliser auto dans les attributs de lambda. Le souci c'est que dans ce cas il faut g�n�raliser � toutes les fontions.
Ya aussi des propositions dans ce genre l� : http://cpp-next.com/archive/2011/11/...-pythy-syntax/

Perso boost::phoenix c'est cool mais la syntaxe et les limitations font que �a m'est trop rarement utile...


Concernant ton exemple, ce que je veux dire c'est si tu ajoutes un peu de code , m�me une ligne, dans le lambda et dans le foncteur, �a donne une meilleure id�e pour comparer les deux "� la lecture".

C'est justement de cette article que je sais que c'est li� � une limitation li�s aux concepts :

Citation:

---

nobody could figure out how to integrate polymorphic lambdas with concepts

---

Citation:

---

Personne n'a pr�senter d'int�gration des lambdas polymorphique compatible avec les concepts

---

Mais � vrai dire j'en sais pas plus ...

C'est vrai que d�s qu'on fait quelque chose d'un peu compliqu� boost::phoenix demande de s'adapter � une nouvelle syntaxe (si c'est quelque chose de vraiment simple, la syntaxe est plus simple que celle du standard je trouve), mais on n'a pas r�element besoin de lambda polymorphique tout le temps non plus (*) (c'est d'ailleurs une des justifications du comit� pour la non int�gration des lambda polymorphiques je crois).

(*) Un besoin r�el, pas juste pour simplifier la syntaxe d'�criture de la lambda.

Salut,
Un avantage des lambda est de permettre de limiter la port�e d'un traitement aux seuls endroits o� on en a vraiment besoin. Un foncteur classique sera visible sur un scope plus important et viendra donc 'polluer' celui-ci.

Je ne pense pas que son seul int�r�t soit de remplacer un std::bind (m�me si les constructions avec un lambda peuvent �tre plus digestes). L'int�r�t va �merger au fur et � mesure de l'identification des bonnes pratiques de son utilisation.

Pour l'instant, comme Klaim, je les vois tr�s clairement devenir indispensables dans les algos (STL ou autres), les visiteurs, pour cr�er des fabriques � la vol�e.

En revanche, je m'en m�fie dans les syst�me �v�nementiel (et donc tout ce qui ressemble � du signal ou du observateur) car l�, la lecture du code et le debuggage deviennent plus chaud.

@Emmanuel : comme Arzar, je pense que ton exemple montre beaucoup plus l'int�r�t de std::function que celui des lambda. std::function qui sont aussi quelque chose qui se propagent comme la mis�re sur le monde dans mon code.