Discussion :

[Jean-Marc.Bourguet]

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.

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?

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

[Emmanuel Deloget]

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

WG21?

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

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.

[Goten]

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.

[Jean-Marc.Bourguet]

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.

[JolyLoic]

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.

[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

[Goten]

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

[Alp]

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