expression lambda evaluee qu'une seule fois

Version imprimable

16/12/2009, 12h41
vandamme

expression lambda evaluee qu'une seule fois
Hello !

Je ne comprends pas pourquoi dans le code ci-dessous, l'expression lambda n'est evaluee qu'une seule fois :
Code:

1 2 3 4 5 6 vector<int*> v(2); v[0] = 0; v[1] = 0; for_each(v.begin(), v.end(), _1 = new int);
Si par contre, je travaille avec des int au lieu de int*, l'expression suivante est bien evaluee pour chaque element du vecteur (2 fois ici donc) :
Code:

1 2 3 vector<int> v(2); for_each(v.begin(), v.end(), _1 = _1+1);
Si qqun avait une explication .....

C'est possible avec boost.phoenix (une généralisation de boost.lambda)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #include "boost/spirit/include/phoenix.hpp" #include <algorithm> #include <vector> using namespace boost::phoenix; using namespace boost::phoenix::arg_names; int main() { vector<int*> v(2, NULL); int i = 0; // c'est bien new_ et pas new std::for_each(v.begin(), v.end(), arg1 = new_<int>(ref(i)++)); printf("%d %d\n", *v[0],*v[1]); }
Mais à vrai dire, je n'ai pas d'explication, car je ne comprends absolument rien au fonctionnement interne de lambda ou phoenix. :aie:

16/12/2009, 14h22
Alp

C'est juste qu'en C++, la stratégie d'évaluation des arguments est stricte. Si on veut appliquer une lambda-expr à chaque élément d'un vecteur, il faut que d'une façon ou d'une autre on retarde le new, qui est le seul élément perturbateur ici. C'est pour ça qu'il y a un new_. Car sinon on fait un new int, et on va assigner ce même int* aux deux éléments du vecteur. Tu vois la différence ?
16/12/2009, 14h40
Arzar

Aaaah oui, j'ai compris, merci :ccool:

En fait new_() appelle le constructeur d'une fonction-objet dont l'opérateur() fait un new. C'est cet opérateur() qui sera appelé autant de fois qu'il y a d'élément dans le for_each...
16/12/2009, 19h14
JolyLoic

Juste pour rappeler que des vraies expressions lambda commencent à être gérées par les compilateurs courants. Jusqu'ici, je me suis refusé à utiliser boost::lambda qui, bien qu'un merveilleux tour de force technique, restent un peu de l'ordre de la bidouille à mon sens.
16/12/2009, 19h38
Alp

Citation:

Envoyé par Arzar

En fait new_() appelle le constructeur d'une fonction-objet dont l'opérateur() fait un new. C'est cet opérateur() qui sera appelé autant de fois qu'il y a d'élément dans le for_each...

C'est tout à fait ça !

Citation:

Envoyé par JolyLoic

Juste pour rappeler que des vraies expressions lambda commencent à être gérées par les compilateurs courants. Jusqu'ici, je me suis refusé à utiliser boost::lambda qui, bien qu'un merveilleux tour de force technique, restent un peu de l'ordre de la bidouille à mon sens.

Boost.Phoenix est meilleure ! Et on est en train de la réimplémenter. Mais dommage qu'ils ne fassent pas de lambdas polymorphes pour 0x.
16/12/2009, 19h52
Goten

Je plussoie pour boost.pheonix. Et pour les lambda polymorphique j'ai pas suivi mais c'est définitivement abandonné?
16/12/2009, 21h17
Alp

Pour 0x oui on dirait.
17/12/2009, 01h13
JolyLoic

Citation:

Envoyé par Goten

Je plussoie pour boost.pheonix. Et pour les lambda polymorphique j'ai pas suivi mais c'est définitivement abandonné?

Ça n'en n'a jamais fait partie, nuance ;)

Pour l'instant, je ne pense pas que ce soit une si grosse perte. Des lambdas non polymorphiques vont déjà bien rendre service, et ils s'implémentent plsu simplement (si la proposition d'avoir des lambdas polymorphiques n'est pas passée, c'est qu'ils ne sont pas si simples que ça... En quoi, je n'en sais rien, je n'y étais pas, mais je crois bien que le ration intérêt/difficulté n'a pas été jugé rentable).

J'ai un peu l'impression que si on ouvre la porte aux lambdas polymorphes, on ouvre aussi la porte aux fonction implicitement template (qui ont été proposées en même temps que auto, et je ne suis pas certain qu'on ai vu les conséquences.
bool f(auto x, auto y) { return x<y; }

Franchement, il faudra me montrer un exemple très convainquant d'utilisation de lambdas polymorphes pour me faire changer d'avis.
17/12/2009, 01h15
Alp

Elles sont bien plus compliquées à intégrer dans le langage de par tous les conflits que ça pourrait entraîner, la résolution des surcharges d'opérateurs complètement tordues, etc. Bref, faire une implémentation robuste c'est un travail de titan. Y'a qu'à voir comment est construite Phoenix actuellement (on retrouvera les mêmes principes dans la prochaine version), et imaginer ça au niveau du langage :aie:

Sinon j'avais pas vu les fonctions implicitement templates ! C'est sympa d'emprunter certaines idées de ce genre aux langages fonctionnels :) C++ va avoir l'air plus jeune ;)
17/12/2009, 14h49
JolyLoic

Citation:

Envoyé par Alp

Sinon j'avais pas vu les fonctions implicitement templates ! C'est sympa d'emprunter certaines idées de ce genre aux langages fonctionnels :) C++ va avoir l'air plus jeune ;)

Sauf que quand ça a été proposé (en même temps qu'auto ?), ça a été assez mal reçu je crois (en gros, "c'est quoi ce truc !"). Mais c'était il y a longtemps, je ne me souviens plus trop des détails. Est-ce que ça réapparaître pour C++XX ? Je n'en sais rien.