boost phoenix vs lambda c1x

Version imprimable

14/12/2010, 21h56
guillaume07

boost phoenix vs lambda c1x

Bonjour,

Il me semble avoir déjà lu que les lambda de phoenix comporter un avantage par rapport aux lambdas de C1xx..si quelqu'un à l'info..

Par ailleurs y a t-il une différence à ce que les lambdas expression ne soit pas définit dans le core language? notamment en terme de performance

Merci
15/12/2010, 09h44
Goten

Citation:

Il me semble avoir déjà lu que les lambda de phoenix comporter un avantage par rapport aux lambdas de C1xx..si quelqu'un à l'info..

Elles sont polymorphiques.

Citation:

Par ailleurs y a t-il une différence à ce que les lambdas expression ne soit pas définit dans le core language? notamment en terme de performance

Oui la syntaxe plus légère. Non pour les perfs.
19/12/2010, 12h10
guillaume07

dans quel cas finalement a t-on besoin de lambda polymorphic? si je comprends bien il s'agit de lambda expression qui peuvent être templater ?

par exemple si on a un boost::any que l'on souhaite le parcourir avec un std::for_each et appliquer la même lambda expression sur chacun de ces éléments, en c++0X on est bloqué ? (sauf à utiliser un void* obv)
19/12/2010, 14h15
Flob90
Une fonction lambda polymorphique serait une fonction lambda où l'on a pas besoin de spécifier le type du paramètre, ie où il est déduit automatiquement :
Code:

1 2 3 [](int i){return i;} //monomorphic lambda [](i){return i;} //polymorphic lambda
Les raisons du comité de les avoir exclu sont :
- La peur d'avoir quelque chose d'illisible
- Complication de vérification du typage (lié au méchanisme qui voulait être mis en place pour les concepts)
- Donc deux difficultés pour quelque chose que sert assez peu (cf NB)

Eric Niebler [1] donne un autre argument en faveur des lambda de boost, c'est qu'ils ont une structure d'arbre qui peut être manipulé à la compilation.

Sources:
- http://www.open-std.org/jtc1/sc22/wg...2006/n1968.pdf (section 5.1)
- [1] http://cpp-next.com/archive/2010/10/...sion-part-one/ (encadré latéral)

NB: Je ne fais que rapporter les éléments d'un document du comité, je n'ai pas utilisé assez les lambda ni ne connait assez bien la théorie qui est dérière pour savoir si ca sert souvent ou pas.
19/12/2010, 14h27
guillaume07

all right thanks
19/12/2010, 16h22
Goten

y'a un patch gcc qui implémente les lambda polymorphiques d'ailleurs.

Et pour leur utilité, essaye d'utiliser un mpl::for_each avec une lambda :mrgreen:
19/12/2010, 16h43
Flob90

Je trouve pas mpl::for_each dans la doc de mpl.
19/12/2010, 17h02
guillaume07

http://www.boost.org/doc/libs/1_39_0.../for-each.html
c'est pas ça ?
19/12/2010, 17h04
Flob90

Ha oui, elle y était pas dans la doc en pdf :)

Enfin ca ne change rien au dire du comité, ils ont pas dit inutile mais rarement utile, et mpl::for_each est quand même pas ce qu'utilise le plus souvent les développeurs.

Mais c'est vraie que dans ce cas là ca serait bien pratique. :ccool:

GCC l'ajoute comme une extension ? Au même titre que le VLA par exemple ?
19/12/2010, 19h12
Goten

Nan c'est un patch, à toi de l'appliquer si tu veux test :
http://gcc.gnu.org/ml/gcc/2009-08/msg00174.html

(expérimental toussa toussa).
19/12/2010, 19h54
guillaume07

ça se stock une lambda expression où on s'en sert juste à l'endroit du code et elle est définit ?
19/12/2010, 21h04
Goten

Code:

auto f = [] {};
19/12/2010, 22h11
guillaume07

jolie
20/12/2010, 16h59
Emmanuel Deloget

Citation:

Envoyé par guillaume07

jolie

En fait, le type d'une lambda (car les lambda ont un type, et voui) est librement défini par le vendeur de compilateur. Du coup, pour stocker une lambda, on est obligé définir une variable auto. De même, pour passer une lambda en paramètre, on est obligé d'utiliser les templates (et la déduction automatique de type).
21/12/2010, 00h38
guillaume07

Citation:

Envoyé par Emmanuel Deloget

En fait, le type d'une lambda (car les lambda ont un type, et voui) est librement défini par le vendeur de compilateur. Du coup, pour stocker une lambda, on est obligé définir une variable auto. .

un boost::function qui va bien ça passe aussi, non ?
21/12/2010, 09h41
Emmanuel Deloget
Citation:

Envoyé par guillaume07

un boost::function qui va bien ça passe aussi, non ?

Du point de vue du code utilisateur, on peut alors passer n'importe quel callable - fonction, objet fonction, lambda, ... C'est probablement ce qui fait la beauté de la chose.
Code:

1 2 3 4 5 template <class _Callable> int f(_Callable arg) { return arg(); }
Ce code prends n'importe quoi qui accepte la syntaxe d'appel d'une fonction sans argument, y compris boost::function si je ne m'abuse (mais pour être tout à fait franc, boost m'agace au plus haut point et je ne l'utilise pas ; donc j'en sais trop peu pour pouvoir me prononcer avec exactitude, et je suis trop fainéant pour faire la recherche qui s'impose :))
21/12/2010, 11h32
Goten
Citation:
Envoyé par Emmanuel Deloget

Code:

1 2 3 4 5 template <class _Callable> int f(_Callable arg) { return arg(); }

Ce code prends n'importe quoi qui accepte la syntaxe d'appel d'une fonction sans argument, y compris boost::function si je ne m'abuse (mais pour être tout à fait franc, boost m'agace au plus haut point et je ne l'utilise pas ; donc j'en sais trop peu pour pouvoir me prononcer avec exactitude, et je suis trop fainéant pour faire la recherche qui s'impose :))
Bien entendu... c'est qu'un foncteur après tout...

(ps : un underscore suivi d'une majuscule... tss tss, tu nous as habitué à mieux :p)
21/12/2010, 13h40
guillaume07
Citation:
Envoyé par Emmanuel Deloget

Du point de vue du code utilisateur, on peut alors passer n'importe quel callable - fonction, objet fonction, lambda, ... C'est probablement ce qui fait la beauté de la chose.

Code:

1 2 3 4 5 template <class _Callable> int f(_Callable arg) { return arg(); }

Ce code prends n'importe quoi qui accepte la syntaxe d'appel d'une fonction sans argument, y compris boost::function si je ne m'abuse (mais pour être tout à fait franc, boost m'agace au plus haut point et je ne l'utilise pas ; donc j'en sais trop peu pour pouvoir me prononcer avec exactitude, et je suis trop fainéant pour faire la recherche qui s'impose :))
...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

:P
21/12/2010, 14h35
Emmanuel Deloget

Citation:

Envoyé par guillaume07

...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

:P

Je ne vais pas dire le contraire (je suis même assez d'accord avec eux, et il y a certains composants qui ont trouvé leur chemin vers la librairie standard, ce qui démontre assez bien ce point). Mais quand je pense à boost, il y a un mot qui me vient à l'esprit : convoluted :)

Citation:

Envoyé par Goten

(ps : un underscore suivi d'une majuscule... tss tss, tu nous as habitué à mieux :p)

J'ai (un peu) honte, effectivement.

Le coup a été pris lorsque j'ai tenté de ré-implémenter certaines parties du TR1 et de la librairie standard. On notera que le texte du standard dit que ces symboles sont réservés à l'implémentation de la librairie standard (17.4.3.1.2, clause 1) au niveau global, pour n'importe quel usage (donc l'utilisation dans la ré-implémentation d'une partie de la librairie standard ou du TR1 est tout à fait valide). Pour qu'un tel usage ait un impact sur la définition d'un template, il faut que ce symbole soit utilisé pour définir une macro - sauf que dans ce cas, le standard dit (en creu) qu'il faut préférer la forme '_'+minuscule (puisqu'une macro est un symbole dans le namespace global; même paragraphe, même clause). L'autre cas, c'est la définition par le compilateur lui même d'un mot-clef ou d'un symbole ayant un sens particulier dans le contexte d'une librairie (mais les compilateurs préfèrent '__', qui est équivalent à '_'+majuscule).

Je sais qu'il s'agit là d'une erreur, mais je m'autorise à transgresser la règlementation - pour de mauvaises raisons, qui sont :

1) j'aime bien
2) je n'ai pas eu de problème avec depuis que j'ai commencé à l'utiliser.

J'ai prévenu, ce sont de mauvaises raisons :)

En fait, lorsqu'on étudie le code des librairies standard du marché, on voit que cette convention n'est utilisée quasiment que pour les paramètres de templates (je n'ai pas trouvé d'autres cas). Le cas approchant, c'est '_'+minuscule (réservé pour définir des noms dans le namespace global; je ne l'utilise jamais). Ce cas là est fréquent, pour des raisons évidentes (macros privées, fonctions privées mais déclarées dans les headers afin d'être utilisées dans des macros évoluées, etc.).

Mais je le reconnais, c'est une mauvaise chose.

Dans le même temps, j'ai besoin d'une convention claire pour nommer mes paramètres templates - et celle là me parait tout à fait adaptée. De toute façon, ces symboles n'apparaissent que très peu dans mon code, puisque les paramètres templates sont immédiatement réimportés dans les classes et fonctions les utilisant sous une forme aliasée (par typedef pour les types, par des static const pour les valeurs intégrales).

Une autre solution serait de supprimer le premier underscore (et donc garder la première majuscule, mais dans ce cas, je risque des conflits avec des librairies (que je pourrais utiliser) et qui utilise des noms de symboles en Camel Case dans le namespace globale. Je serais plus standard, mais je n'en serais pas moins bloqué :)

A mon sens, le WG21 a voulu trop en faire : en déclarant que '__' et '_'+maj étaient équivalents, ils n'avaient pas forcément prévu que '__' serait utilisé de manière systématique pour définir de nouveaux token ou symboles ayant un effet global, et que '_'+maj ne serait jamais (ou très rarement ; si rarement que je ne l'ai jamais vu) utilisé que pour définir des symboles n'ayant qu'une portée locale.

Je le répète encore : ce n'est pas bien (donc, jeune développeur, ce n'est pas parce que je le fait qu'il faut faire de même ; c'est une mauvaise chose, et la branche armée du WG21 pourrait fort bien venir te voir et te faire passer cette envie décadente).

(merci tout de même de m'avoir lancé sur le sujet ; j'avais des choses à dire, visiblement !)
21/12/2010, 14h59
JolyLoic

Citation:

Envoyé par guillaume07

un boost::function qui va bien ça passe aussi, non ?

Oui. Mais on perd en perf, de manière non négligeable, si j'ai bien suivi.
21/12/2010, 15h05
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Deloget

Je ne vais pas dire le contraire (je suis même assez d'accord avec eux, et il y a certains composants qui ont trouvé leur chemin vers la librairie standard, ce qui démontre assez bien ce point). Mais quand je pense à boost, il y a un mot qui me vient à l'esprit : convoluted :)

boost ne m'agace pas. Ce qui m'agace c'est l'attitude "hors de boost, point de salut". Et ceux qui prennent l'implementation de boost comme exemple de bon code. Les interfaces sont souvent bien, mais les implementations tiennent compte de trop de facteurs pratiques pour servir d'exemple a ceux pour qui certains des facteurs ne sont pas pertinents.

Citation:

A mon sens, le WG21 a voulu trop en faire : en déclarant que '__' et '_'+maj étaient équivalents, ils n'avaient pas forcément prévu que '__' serait utilisé de manière systématique pour définir de nouveaux token ou symboles ayant un effet global, et que '_'+maj ne serait jamais (ou très rarement ; si rarement que je ne l'ai jamais vu) utilisé que pour définir des symboles n'ayant qu'une portée locale.

WG21?

Citation:

Envoyé par ISO/IEC 9899: 1990

— All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary identifier and tag name spaces.

Et le comite C a une forte tendance a utiliser la forme _[A-Z] pour commencer ses nouveaux keywords avec un entete definissant des macros avec des noms sans _ initial.

(En passant si j'ai bonne memoire, le fait que _[A-Z] est reserve a ete utilise dans certains algo de manglings -- mais ca ne devrait pas te poser de problemes pour les noms de parametres templates).
21/12/2010, 16h52
Emmanuel Deloget

Citation:

Envoyé par Jean-Marc.Bourguet

boost ne m'agace pas. Ce qui m'agace c'est l'attitude "hors de boost, point de salut". Et ceux qui prennent l'implementation de boost comme exemple de bon code. Les interfaces sont souvent bien, mais les implementations tiennent compte de trop de facteurs pratiques pour servir d'exemple a ceux pour qui certains des facteurs ne sont pas pertinents.

Aussi, oui ;)

Citation:

Envoyé par Jean-Marc.Bourguet

WG21?

Workgroup 21, le comité de normalisation du C++.

Citation:

Envoyé par Jean-Marc.Bourguet

Et le comite C a une forte tendance a utiliser la forme _[A-Z] pour commencer ses nouveaux keywords avec un entete definissant des macros avec des noms sans _ initial.

(En passant si j'ai bonne memoire, le fait que _[A-Z] est reserve a ete utilise dans certains algo de manglings -- mais ca ne devrait pas te poser de problemes pour les noms de parametres templates).

Info intéressante. Il faudra que je regarde ça.
21/12/2010, 16h55
Goten

Citation:

Envoyé par JolyLoic

Oui. Mais on perd en perf, de manière non négligeable, si j'ai bien suivi.

Y'a une nouvelle implémentation de boost::function dans les tubes qui explose un peu tout d'ailleurs... Mais j'ai pas suivi l'histoire de trop prêt.
21/12/2010, 17h08
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Deloget

Workgroup 21, le comité de normalisation du C++.

J'ai ete trop laconique. La citation qui suivait montrait que le coupable etait X3J11/WG14 que le fait avait ete accompli a un moment ou WG21 n'existait pas encore.
21/12/2010, 17h55
JolyLoic

Citation:

Envoyé par Goten

Y'a une nouvelle implémentation de boost::function dans les tubes qui explose un peu tout d'ailleurs... Mais j'ai pas suivi l'histoire de trop prêt.

Et moi pas du tout, donc ce qui suit n'est pas un avis vraiment informé : Le fait est que les lambdas sont directement visibles, et donc aisément inlinables dans le code appelant. Les std::function ou autres variantes me semblent devoir passer quelque part par un pointeur de fonction, qui va casser les possibilités d'inlining des compilateurs courants.

C'est ce pointeur qui fait leur force en flexibilité (modifiable au run-time), mais aussi leur faiblesse en perfs.
22/12/2010, 11h56
Alp

Les lambdas de C++1x, phoenix et autres, finalement quand on a goutté sérieusement aux vraies lambdas, et plus généralement à un langage qui aide vraiment à manipuler des fonctions comme on le veut, ça paraît fade tout ça...

Et oui LoÏc, on ne peut pas vraiment bien inliner, ni fuser, ni rien du tout. Y'a tout un tas d'optimisations qui s'envolent :?
22/12/2010, 12h02
Goten

Citation:

Envoyé par Alp

Les lambdas de C++1x, phoenix et autres, finalement quand on a goutté sérieusement aux vraies lambdas, et plus généralement à un langage qui aide vraiment à manipuler des fonctions comme on le veut, ça paraît fade tout ça...

Et oui LoÏc, on ne peut pas vraiment bien inliner, ni fuser, ni rien du tout. Y'a tout un tas d'optimisations qui s'envolent :?

Oh et entendez le l'autre qui fait sa propagande fonctionnelle :'.
</sarcasm>

Les lambdas (que ça soit phoenix ou 1x) s'inlinent très bien hein...
22/12/2010, 14h04
Alp

Il parlait des std::/boost:: function.