Discussion :

[guillaume07]

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

[Goten]

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.

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.

[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)

[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 :

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

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.

[guillaume07]

all right thanks

[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

[Flob90]

Je trouve pas mpl::for_each dans la doc de mpl.

[guillaume07]

http://www.boost.org/doc/libs/1_39_0.../for-each.html
c'est pas ça ?

[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.

GCC l'ajoute comme une extension ? Au même titre que le VLA par exemple ?

[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).

[guillaume07]

ça se stock une lambda expression où on s'en sert juste à l'endroit du code et elle est définit ?

[Goten]

Code :

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

auto f = [] {};

[guillaume07]

jolie

[Emmanuel Deloget]

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).

[guillaume07]

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 ?

[Emmanuel Deloget]

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 :

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

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 )

[Goten]

Code :

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

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)

[guillaume07]

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 :

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

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

[Emmanuel Deloget]

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

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

(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 !)

[JolyLoic]

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.