Discussion :

[white_tentacle]

si on prend par exemple le tutoriel bien débuter en C++, les liens proposés ne parlent pas de conception.

C'est peut-être pour ça qu'il s'appelle "Bien débuter en C++" et pas "Apprendre le développement avec C++" .

[CedricMocquillon]

C'est peut-être pour ça qu'il s'appelle "Bien débuter en C++" et pas "Apprendre le développement avec C++" .

Exact ce que je pointe c'est qu'il manque justement ce fameux tuto "Apprendre le développement avec C++" qui serait aussi utile pour le C++ que ceux plus "techniques"

[yan]

Ouais, c'est sur que ce genre de syntaxe va attirer beaucoup de monde au C++ moderne...

c'est juste un exemple. Écrire des foncteurs peut être chiant. C'est surement pour cela que c'est peu utilisé.

Boost fournie des outils pour simplifier tous cela. La prochaine norme te permet d'écrire directement de foncteur dans le foreach.
http://en.wikipedia.org/wiki/C%2B%2B...nd_expressions

[Alp]

Corrigez moi si je me trompe (Alp puisque tu suis la discussion...) mais je suis quand même d'accord avec le PO: entendons nous bien, je ne remet pas du tout en cause vos compétences respectives (c'est à lire vos posts que j'ai réellement progressé en C++) mais si on prend par exemple le tutoriel bien débuter en C++, les liens proposés ne parlent pas de conception.

Oui, car c'est bien débuter en C++, pas bien débuter en conception/archi logicielle.
Je tiens quand même à citer un passage de mon article :

IV. Ce n'est pas suffisant ?
Non, un cours et/ou un livre sur le C++ ne sont pas suffisants. En effet, ces derniers répondent au problème du "comment" (comment écrire un logiciel qui fait ceci ou cela), alors qu'il y a aussi le problème du "pourquoi". Il vous faudra impérativement, si vous êtes un débutant total en programmation, vous munir d'un ou plusieurs ouvrages et/ou cours sur :

* L'algorithmique et les structures de données : il vous faudra souvent, lorsque vous programmez, stocker des données de manière intelligente et efficace, mais surtout appropriée à l'usage qui en est fait. Connaitre les structures de données les plus utilisées ainsi que leurs caractéristiques est un élément très important. De même, connaître les bases de l'algorithmique (variables, boucles, complexité, invariants, ...) est tout aussi nécessaire pour que vous écriviez de bons programmes. Vous pouvez vous référer à la page Algorithmique pour ce faire ;
* La conception logicielle : il vous faudra savoir organiser intelligemment les différentes parties de vos programmes de sorte à pouvoir facilement introduire des évolutions dans ce dernier, par exemple. Pour ce faire, il y a également une certaine connaissance à acquérir et à mettre en pratique. Vous pouvez vous référer à la page Conception pour ce faire.

Les principes "techniques" sont souvent cités RAII, polymorphisme statique, classes de trait ou de politique, couplage faible, mais rarement, on voit leur mise en œuvre concrète dans un projet orienté métier. On trouve de bon tutos sur dvp sur certains de ces points mais au final je pense que ce qu'il manque aux débutant et au PO ce serait un tuto sur la mise en application "concrète" de ces principes (appli de gestion de personnels, de stock-produits, etc...)

C'est une excellente chose que tu proposes des sujets/types d'articles ! Si personne ne nous le dit, on écrit sur ce qui nous semble intéressant etc. Mais je vais personnellement essayer de prendre ta remarque en compte.

Par contre, je te certifie que j'utilise beaucoup de ces principes et techniques au quotidien là

[Issam_Lahlali]

...
Il va falloir se décider : soit tu imposes XML, soit tu ne l'imposes pas. Tu ne peux pas penser une chose et son contraire.

je crois avoir répandu a ça juste avant ou j'explique que dans mon contexte et ma manière de faire les choses ou je peux utiliser dans le même projet plusieurs technos et langages que pour moi XML comme solution qui facilite la conception et l'architecture et le fait de parler de XML n'est pas hors de sujet, c'est un choix d'architecture et de conception.

c'est pour cela que je défend une idée dans un contexte et j'impose pas , et d'ailleurs je ne peux pas imposer a personne quoi que ce soit, chacun analyse en dépend de la nature de son projet pour faire son choix.

et finalement il n y a pas XML ou pas, tout dépend de ce qu'on fait et dans le cas de QML je défends XML.


mais finalement puisque le choix de XML ne fait pas parti des choix de conception je pense que ça sera mon dernier post sur XML.

[Issam_Lahlali]

Pour revenir a la question initiale et en prenons en compte les différentes réponses voici mon point de vue par rapport au monde du C++:

J'ai l'impression que de plus en plus en C++ on suit le principe de la sélection humaine prôné par nietzsche ou on se dit ceux qui arrivent a nous suivre tant mieux et les autres tant pis.

et finalement on se retrouve avec une élite isolé ou il y a quelques personnes et on commencent a se venter qu'on est les meilleurs et c'est la faute des autres qui n'arrivent pas a suivre, et ça se voient aussi sur les réponses du genre tu connais rien de rien et finalement j'entends implicitement t'arrive pas a suivre.

croyez moi je sais autant que vous qu'utiliser C++ pendant des années rend ces mécanismes simples et intuitives mais pour un débutant il voit devant lui une montagne infranchissable, alors si en plus on lui dit t'arrive pas a suivre il va chercher ailleurs.

mais il faut savoir qu'un génie au milieu de gens normaux c'est lui qui devient normal et tout le monde s'en fout d'entendre ces choix même si ils sont intéressants.

il faut au même temps être sage aussi pour descendre au niveau de tout le monde pour faire passer le message.

a mon avis la maniére de présenter C++ est a sa jeunesse ou on commence a se venter de nos compétences et de ce qu'on est capable de faire, mais elle n'est pas arriver encore a l'age de maturité et je crains que si ça continue comme ça il va entrer a l'age de retraite directement.

finalement a quoi sert un langage très très très puissant mais avec juste une élite qui maitrise soit disant son aspect moderne, c'est comme une arme très sophistiqué mais qu'on arrive pas a bien maitriser ou le mieux des fois est de ne pas utiliser, ça risque d'exploser sur nous même.

et malheureusement le constat est la , moins de jeunes qui s'intéressent a c++ et beaucoup de boites qui commence a fuir C++.

et c'est vrai qu'il n y a pas une solution magique qui règle le problème mais il faut juste être conscient de l'état ou se trouve C++.

a mon avis la conception joue et elle a jouer un rôle important dans l'histoire de C++ d'où l'objet de ma question initiale.

[Invité]

c'est juste un exemple. Écrire des foncteurs peut être chiant. C'est surement pour cela que c'est peu utilisé.

Boost fournie des outils pour simplifier tous cela. La prochaine norme te permet d'écrire directement de foncteur dans le foreach.
http://en.wikipedia.org/wiki/C%2B%2B...nd_expressions

En fait, ma critique de l'approche foncteur (qui se justifie parfaitement dans certains cas) c'est qu'elle a tendance à "éparpiller" le code. La boucle est appelée à un endroit, mais le code qu'elle exécute est ailleurs.

Au delà des problèmes d'optimisation que cela peut poser, cela accroit le nombre de choses qu'il faut avoir en tête quand on relit (qu'on débugue) du code, surtout du "code des autres". En fait, cela revient à échanger une facilité d'écriture contre une difficulté de relecture, et je ne suis pas sur que ce soit une bonne idée. En informatique, le problème est plus souvent de relire le code que de l'écrire...

Les lambdas fonctions, je les attends avec intérêt. Personnellement, je trouve l'approche séduisante pour la raison citée au paragraphe précédent : elles permettent d'éviter l'éparpillement.

Maintenant, elles introduisent aussi deux risques majeurs :

1- l'abandon de la structuration procédurale du code (en caricaturant, ou pourrait se retrouver avec une seule grande fonction qui passe du code), qui peut rendre les programmes inmaintenables (en tous cas par des programmeurs formés aux méthodes précédentes)
2- la difficulté de relecture quand les bouts passés en lambda deviennent un peu complexes.

Quant au lien fait entre lambda et foncteurs, je dois dire que je ne comprends pas. L'approche foncteur consiste à sortir le code de la boucle, pour pouvoir le réutiliser, sans doute. L'approche lambda consiste à l'y remettre. Finalement foncteur+lambda va revenir à ce qu'on faisait au départ, avec juste une syntaxe différente. J'ai du mal, là (et dans la tête des tas d'images d'actes de barbarie impliquant des mouches)...

Une fois de plus, je ne suis pas du tout certain que ces améliorations rendent le C++ à nouveau attractif, ni qu'elles améliorent la qualité du code produit en entreprise.

Francois

[saad.hessane]

Les principes "techniques" sont souvent cités RAII, polymorphisme statique, classes de trait ou de politique, couplage faible, mais rarement, on voit leur mise en œuvre concrète dans un projet orienté métier. On trouve de bon tutos sur dvp sur certains de ces points mais au final je pense que ce qu'il manque aux débutant et au PO ce serait un tuto sur la mise en application "concrète" de ces principes (appli de gestion de personnels, de stock-produits, etc...)

Moi je suis totalement d'accord avec cela. Un exemple de projet serai très apprécié.
Si j'ai apprécié Accelerated C++ (que je n'ai pas encore terminé), c'est qu'il apprend à travers des exemples concret, genre gestion des notes d'étudiant... Ça change quand même des voitures qui héritent de véhicule ou carré de rectangle...
Mais le mieux, c'est d'avoir un cours surtout en conception, comment se comporter avec le projet. Avec des exemples de couplage faible/fort (c'est des mots que j'ai lu sur vos posts), de C++ "moderne", un peu de tout quoi.

[pseudocode]

Mais le mieux, c'est d'avoir un cours surtout en conception, comment se comporter avec le projet. Avec des exemples de couplage faible/fort (c'est des mots que j'ai lu sur vos posts), de C++ "moderne", un peu de tout quoi.

Autant je connais des techniques de conception mono paradigme, autant je me demande a quoi peut ressembler une conception "multi-paradigmes" spécialement conçue pour le C++.

[Luc Hermitte]

Vous avez le livre de Coplien : Multiparadigm Design in C++. Vous n'y trouverez que très peu de code dedans. La thèse à l'origine du livre est disponible en ligne. J'ai vu assez peu de différence entre bouquin et thèse.

[white_tentacle]

Une fois de plus, je ne suis pas du tout certain que ces améliorations rendent le C++ à nouveau attractif, ni qu'elles améliorent la qualité du code produit en entreprise.

Ça dépend desquelles on parle. auto, par exemple, est un progrès quasi-indiscutable.

Quant au lien fait entre lambda et foncteurs, je dois dire que je ne comprends pas. L'approche foncteur consiste à sortir le code de la boucle, pour pouvoir le réutiliser, sans doute. L'approche lambda consiste à l'y remettre. Finalement foncteur+lambda va revenir à ce qu'on faisait au départ, avec juste une syntaxe différente. J'ai du mal, là (et dans la tête des tas d'images d'actes de barbarie impliquant des mouches)...

Pas tout à fait. Parcourir une liste chaînée ne se fait pas avec un for(i = 0; i < size ;++i). Les itérateurs sont une mauvaise solution qui permet d'abstraire le parcours. Les algorithmes de parcours (std::for_each et consorts) sont une abstraction supplémentaire, meilleure. La syntaxe est différente, le niveau d'abstraction aussi. De plus, les lambdas ne s'utilisent pas que dans les boucles, mais dans tous les algorithmes prenant un foncteur. C'est beaucoup plus souple que "ce qu'on faisait au départ"

[pseudocode]

Vous avez le livre de Coplien : Multiparadigm Design in C++. Vous n'y trouverez que très peu de code dedans. La thèse à l'origine du livre est disponible en ligne. J'ai assez peu peu de différence entre bouquin et thèse.

Intéressant. Un premier survol rapide me fait penser que le plus gros de l'effort intervient dans la phase d'analyse:

- Divide the problem into intuitive subdomains
- Analyze each application subdomain
- Analyze the solution domains
- Map from application domain analysis onto available solution domain analyses

Je vais lire ça plus attentivement, merci.

[nikko34]

La différence entre un foncteur et un pointeur de fonction donné en paramètre à une fonction de tri en C, n'est quand même pas énorme. Il n'y a pas un fossé idéologique entre les deux. Et l'avantage du functor est justement d'utiliser un objet avec ses états etc...

Pareil pour les iterateurs, si on te dit: pour parcourir un container, utilise un iterateur, les gens le font. Même en Java. Et c'est sûr qu'utiliser le foreach est bien mieux.

[saad.hessane]

Vous avez le livre de Coplien : Multiparadigm Design in C++. Vous n'y trouverez que très peu de code dedans. La thèse à l'origine du livre est disponible en ligne. J'ai vu assez peu de différence entre bouquin et thèse.

Luc, stp je n'ai pas trouvé la thèse. Si tu pouvais nous mettre le lien.

[Invité]

Pas tout à fait. Parcourir une liste chaînée ne se fait pas avec un for(i = 0; i < size ;++i). Les itérateurs sont une mauvaise solution qui permet d'abstraire le parcours. Les algorithmes de parcours (std::for_each et consorts) sont une abstraction supplémentaire, meilleure. La syntaxe est différente, le niveau d'abstraction aussi.

Je ne crois pas que cela tienne à la boucle for... ou à l'utilisation d'un indice de parcours ou d'un itérateur... A mon avis, on a les étapes suivantes

Etape zéro

Code :

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

1
2
3
4
5
6
 
// ca ou l'équivalent avec while() ou n'importe quel autre instruction
for(iterateur it=debut;it!=fin;it++) {
     du code...
     encore du code ...
}

Etape un

Code :

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

1
2
3
4
5
6
7
 
Foncteur fonc {
    du code
    encore du code
};
 
foreach(debut,fin,fonc);

On vient donc d'échanger un code plus long mais concentré en son lieu d'appel, contre un code très court, mais réparti en deux endroits (mais réutilisable)

Etape2

Code :

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

1
2
 
foreach(debut,fin,[]{du code... encore du code...});

Je prétends que la différence entre 0 et 2 est essentiellement syntaxique. Et dans ce domaine, je ne suis pas certain que 2 sera plus facile à lire, pour des programmeurs classiques, qui héritent des habitudes passées.

De plus, les lambdas ne s'utilisent pas que dans les boucles, mais dans tous les algorithmes prenant un foncteur. C'est beaucoup plus souple que "ce qu'on faisait au départ"

Là je suis bien d'accord. A mon avis, l'utilisation optimale d'une lambda, c'est un foncteur, ou une fonction, qu'on n'aurait créé(e) qu'une fois, qui a peu de chance de resservir, et qu'il n'y a aucun intéret à isoler. En ce sens, c'est très puissant. Ceci dit, je ne crois pas que cela soit autre chose qu'un raccourci d'écriture (je n'arrive pas à voir des choses que les lambdas permettent, et qu'on ne pourrait faire autrement).

Francois

[CedricMocquillon]

C'est le premier lien google si tu tapes Coplien phd thesisCoplien phd thesis

[metagoto]

Je prétends que la différence entre 0 et 2 est essentiellement syntaxique. Et dans ce domaine, je ne suis pas certain que 2 sera plus facile à lire, pour des programmeurs classiques, qui héritent des habitudes passées.

L'intéret premier en ce qui me concerne, c'est qu'on a un contrôle selectif sur le contexte dans lequel la lambda est éxécutée (une closure). On réunit le meilleur des 2 mondes: un foncteur anonyme (les lambdas dérivent implicitement de reference_closure il me semble) et une facilité d'expression puisqu'on est "sur place".

Les fonctions anonymes sont de plus en plus populaires un peu partout ailleurs. J'ose croire que leur adoption ne sera pas spécialement douloureuse dans c++ (ça me paraît plus simple que les rvalue references par exemple)

[koala01]

Corrigez moi si je me trompe (Alp puisque tu suis la discussion...) mais je suis quand même d'accord avec le PO: entendons nous bien, je ne remet pas du tout en cause vos compétences respectives (c'est à lire vos posts que j'ai réellement progressé en C++) mais si on prend par exemple le tutoriel bien débuter en C++, les liens proposés ne parlent pas de conception.

Le problème se pose pour n'importe quel langage...

Si tu n'a pas un certain "background" d'apprentissage / de connaissance / de maitrise (biffer les mentions inutiles) en analyse des besoins, en conception ou en algorithmie, tu auras toujours difficile à faire les choix les plus adaptés qui te permettront de fournir une application qui rend les services que tu attend d'elle ou à "traquer" l'erreur qui fait qu'elle donne des résultats aberrants

Et c'est vrai quel que soit le langage

Les principes "techniques" sont souvent cités RAII, polymorphisme statique, classes de trait ou de politique, couplage faible, mais rarement, on voit leur mise en œuvre concrète dans un projet orienté métier.

Le fait est que ces différents principes vont, en définitive, s'interpénétrer dans un projet complet, et que, s'il faut commencer par donner uniquement la théorie sur l'ensemble des techniques (histoire de partir d'une "basse commune") avant de partir sur un projet (ne serait-ce que moyen) qui les met en oeuvre de manière concrète, on en arrive facilement à un ouvrage complet et relativement lourd à digérer

On trouve de bon tutos sur dvp sur certains de ces points mais au final je pense que ce qu'il manque aux débutant et au PO ce serait un tuto sur la mise en application "concrète" de ces principes (appli de gestion de personnels, de stock-produits, etc...)

La remarque a déjà été faite, et je suis déjà à la recherche de gens motivés pour ce genre d'article

<mode tpye="appel du pied">d'ailleurs les gars, avez vous lu cette demande de participation</ mode>
Mais la rédaction de tels articles demande une grande dose de temps, de la motivation...

Si tu rajoutes les éventuelles closes de confidentialité ou de cession du code auxquelles on peut être soumis, tu comprendra que les volontaires ne se bousculent pas forcément

Encore une fois ne prenez surtout pas mon post comme une critique c'est juste ce que j'ai ressenti également lorsque j'ai commencé le C++ "moderne".

Si, c'est un critique...
Mais constructive, ce qui fait qu'elle est vraiment la bienvenue

Après tout, le forum (et le site de manière générale) vit beaucoup plus par ceux qui posent des question que par ceux qui y répondent (mais rendons à cesar ce qui appartient à cesar: si ceux qui répondent au question n'étaient pas là, ceux qui les posent en sachant obtenir une solution correcte ne seraient pas là non plus)

Pour revenir a la question initiale et en prenons en compte les différentes réponses voici mon point de vue par rapport au monde du C++:

J'ai l'impression que de plus en plus en C++ on suit le principe de la sélection humaine prôné par nietzsche ou on se dit ceux qui arrivent a nous suivre tant mieux et les autres tant pis.

et finalement on se retrouve avec une élite isolé ou il y a quelques personnes et on commencent a se venter qu'on est les meilleurs et c'est la faute des autres qui n'arrivent pas a suivre, et ça se voient aussi sur les réponses du genre tu connais rien de rien et finalement j'entends implicitement t'arrive pas a suivre.

Ce n'est absolument pas cela...

La situation actuelle (que l'on remarque dans tous les langages d'ailleurs) est plutôt que l'on a d'un côté les gens qui se rendent compte que la connaissance seule d'un langage ne sert à rien s'il n'y a pas un certain background de conception et de l'autre ceux qui croyent (à tord) que l'informatique et particulièrement la programmation, c'est facile, et qui ne veulent pas ou n'envisagent absolument pas de passer par la case "conception et analyse" avant de se jeter sur le clavier... Lorsqu'ils ne suivent pas le raisonnement du "je fais comme cela depuis 30 ans" pour justifier qu'ils n'aient pas voulu évoluer "avec leur temps".

On ne demande généralement pas mieux que de faire évoluer au mieux les gens, encore faut-il qu'il veuillent eux-même évoluer

Bien sur, tu aura toujours des "gourous" qui maitrisent l'ensemble des aspect du langage (et je ne parle pas forcément du C++), et qui seront moins enclins à répondre à une question portant sur la conception ou sur la technique pure (voire, peu capable de donner une explication simple), mais c'est la différence entre les différents profile qui fait que le monde est monde

croyez moi je sais autant que vous qu'utiliser C++ pendant des années rend ces mécanismes simples et intuitives mais pour un débutant il voit devant lui une montagne infranchissable, alors si en plus on lui dit t'arrive pas a suivre il va chercher ailleurs.

Il est clair que l'expérience est quelque chose de primordial...

Mais avant d'en avoir, il faut aussi accepter l'idée que l'on est un débutant, quelle que soit la matière dans laquelle on aspire à gagner de l'expérience

Comme je l'ai dit, les gens ont souvent l'idée fausse que la programmation est facile (quel que soit le langage)...

Et bien souvent, ils croyent que, parce qu'il connaissent la petite centaine de mot clé et de fonction importante d'un langage de programmation, ils le maitrisent parfaitement...

Or, il faut se rendre à l'évidence, ce n'est absolument pas vrai...

mais il faut savoir qu'un génie au milieu de gens normaux c'est lui qui devient normal et tout le monde s'en fout d'entendre ces choix même si ils sont intéressants.

il faut au même temps être sage aussi pour descendre au niveau de tout le monde pour faire passer le message.

C'est ce que la *communauté* fait en permanence...

Maintenant, je ne suis pas aussi catégorique lorsque l'on parle des programmeurs à titre individuel

a mon avis la maniére de présenter C++ est a sa jeunesse ou on commence a se venter de nos compétences et de ce qu'on est capable de faire, mais elle n'est pas arriver encore a l'age de maturité et je crains que si ça continue comme ça il va entrer a l'age de retraite directement.

Je me méfie toujours énormément de ceux qui se contentent de se vanter...

Je préfère bien souvent voir ce dont il est réellement capable

Le problème, c'est que C++ est trop souvent abordé par le "mauvait bout" de la lorgnette

finalement a quoi sert un langage très très très puissant mais avec juste une élite qui maitrise soit disant son aspect moderne, c'est comme une arme très sophistiqué mais qu'on arrive pas a bien maitriser ou le mieux des fois est de ne pas utiliser, ça risque d'exploser sur nous même.

Bien sur que le C++ est puissant et souple

Et je ne nie absolument pas qu'il est également très complexe si tu veux arriver à le maitriser...

Mais, tout comme les armes, j'ai envie de dire qu'il est normal que les langages les plus puissants soit les plus complexes à maitriser et que c'est finalement une chance...

Sinon, n'importe qui pourrait monter dans un bombardier et aller larguer une bombe sur la tour eiffel ou sur le palais royal

La différence qu'il y a, c'est qu'un "bon" programmeur à la base pourra assez facilement s'adapter au C++, alors que, même un bon conducteur aura du mal aux commandes d'un bombardier

et malheureusement le constat est la , moins de jeunes qui s'intéressent a c++ et beaucoup de boites qui commence a fuir C++.

Le constat est là, effectivement...

Et c'est effectivement (du moins pour la partie qui n'est pas due à un effet de mode) à la communauté tout entière de prendre les mesures qui s'imposent, à commencer par... la manière dont il est enseigné (on en revient toujours au même point, finalement )

et c'est vrai qu'il n y a pas une solution magique qui règle le problème mais il faut juste être conscient de l'état ou se trouve C++.

Tu peux me croire, il se trouve dans un état bien meilleur que ce que tes propos semblent suggérer

a mon avis la conception joue et elle a jouer un rôle important dans l'histoire de C++ d'où l'objet de ma question initiale.

La conception est, de manière tout à fait générale, primordiale dés que l'on parle de création d'application, et ce, quel que soit le langage utilisé...

Elle l'est d'autant plus en C++ parce qu'il est multi paradigmes, que, de ce fait, il offre plus de choix lorsque l'on est confronté à un problème particulier, et qu'il faut donc veiller à faire le meilleur choix en fonction des contraints specifiques...

[Arzar]

Je prétends que la différence entre 0 et 2 est essentiellement syntaxique.
Francois

+1
Un foreach + lambda n'apporte rien, AHMA, obscurcit même. En C++0x, La syntaxe la plus courte et la plus expressive pour parcourir un vecteur sera probablement la "range-based for loop" :

Code :

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

1
2
3
4
5
6
 
std::vector<Truc> vec;
for(Truc& truc : vec) 
{
   du code
}

Très pratique, car on a sous les yeux le type contenu dans le vecteur, et on manipule une variable avec un nom qui a du sens (plus besoin d'avoir des "it->" partout ) Et c'est transparent pour les devs qui viennent du C# (foreach(Truc truc in vec){...})
Par contre pour tous les algo "en if", copy_if, remove_if, find_if et tous les algos à prédicat, une lambda est sacrément pratique.

.(je n'arrive pas à voir des choses que les lambdas permettent, et qu'on ne pourrait faire autrement).

Aucune, il me semble. Peut-être d'ailleurs que les compilateurs comme VS ou ICC ont proposé aussi vite les lambdas par le fait qu'il "suffit" de parser la lambda, générer le foncteur équivalent, et compiler normalement. Ceci-dit, ce monsieur fait des trucs assez cool avec les lambdas, qui ne me serait pas venu à l'esprit avec un foncteur.

Edit :

c'est qu'on a un contrôle selectif sur le contexte dans lequel la lambda est éxécutée (une closure).

Qu'est-ce que tu entends par là ?

[koala01]

C'est le premier lien google si tu tapes Coplien phd thesisCoplien phd thesis

(tout à fait HS...: je viens de me rendre compte que Coplien est un "petit belge"... cocoricooo )