Bonjour,
Avec l'arrivé du prochain standard C++, l'implémentation des libs boost sera t-elle obsolète, de part l'arrivée de nouvelle fonctionnalité interne au C++ ?
Merci
Version imprimable
Bonjour,
Avec l'arrivé du prochain standard C++, l'implémentation des libs boost sera t-elle obsolète, de part l'arrivée de nouvelle fonctionnalité interne au C++ ?
Merci
Obsolète dans l'implémentation, je ne pense pas vraiment, à condition de passer sur les versions récentes. A mon avis, le plus gros chantier est la move semantic.
Obsolète dans l'intérêt, partiellement, oui. Certaines bibliothèques de boost seront inclues dans une version plus ou moins modifiée dans le standard (celles déjà dans TR1, par exemple), d'autres seront remplacées par un mécanisme du langage (par exemple, les lambda, (oui, je sais que les lambdas du C++ ne sont pas polymorphes, mais je pense que dans du code applicatif (par opposition à du code de bibliothèque), ce n'est pas vraiment gênant), foreach...).
ok et du nouveau du côté de la date de sortie du C++1X ?
Je pense que ce qui compte le plus, ce n'est pas quand C++1x sortira, mais quand les compilateurs que tu utilises l'implémenteront...
pt1 on y est pas encore deux ans à attendre quoi
Et les variadics ;). (quoique je suis pas sur qu'ils soient adopté partout).
Sinon y'a surtout smart_ptr etc (TR1 quoi ouai). Mais boost sera quand même utile pour la rétro-compatibilité.
Pas si sur que ça, un exemple bête (mais sur lequel des gens se sont déjà cassé les dents) :Citation:
oui, je sais que les lambdas du C++ ne sont pas polymorphes, mais je pense que dans du code applicatif (par opposition à du code de bibliothèque), ce n'est pas vraiment gênant.
mpl::for_each
Salut,Pas si sur...
Si tu prend les compilateurs récents (gcc > 4.4.x, par exemple) tu remarquera que le support de C++1x est déjà au minimum partiel, même si encore taggé "expérimental", et nécessitant d'en activer explicitement le support.
Mais, à bien y réfléchir:
Je crois personnellement que l'on est loin d'être dans la même situation que lorsque C++03 est sorti, où il a fallu plusieurs années pour que la majorité des fournisseurs finissent par supporter (plus ou moins) la norme.
- La version 4.4.1 date déjà de plus d'un an
- On ne peut pas faire autrement que de tagger une possibilité qui n'est même pas encore rendue officielle que "expérimentale" ;)
J'espère donc (ou du moins je veux espérer) que les fournisseurs seront prêts à faire passer la majorité des nouvelles possibilités lorsque la norme sortira effectivement ;)
et concernant MPL et les lambdas ?
avec l'arrivée des lambda c1XX MPL et lambda de boost tombe un peu dans l'oublie non ?
Comme beaucoup de choses qui sont arrivées de Boost dans le standard (n'oublie pas que le TR1 était déjà fortement inspiré de boost à l'époque :D), on peut s'attendre à ce que l'existant reste présent dans boost, essentiellement pour assurer la compatibilité.
Évidemment, il y aura un moment de flottement où l'on se demandera si l'on utilise les lambda de boost ou celles du standard, mais cela cela finira tôt ou tard par se diluer ;)
Et, à coté de cela, il n'est même pas impossible que boost fournisse rapidement des sources d'inspiration pour le TR2 :D
De toutes façons, il faut te dire que le but d'une norme est d'assurer une certaine pérénité, même s'il faut valider de temps en temps des approches "nouvelles" qui entrent dans les moeurs ;)
Avoir une amélioration de la norme tous les 7 à 10 ans entre parfaitement dans le sens de cette évolution ;)
outre ma question en suspend, t'es sûr que niveau performance ça joue dans la même cours phoenix et lambda du core langage ?
c le même code produit, mais pour autant ça ne joue pas dans le même cours ? wtf
Il a pas fait attention à la façon dont tu avais tourné ta question. Oui ça produit la même chose, et oui ça joue dans la même cour.
ok thxs