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
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
boost et C1XX
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...).
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
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...
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
pt1 on y est pas encore deux ans à attendre quoi
Et les variadicsEnvoyé par JolyLoic
. (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) :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
A méditer: La solution la plus simple est toujours la moins compliquée
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), 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
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
rien ne remplace MPL dans le nouveau standard.
Quant au 0x lambda, elles sont monomorphiques et non introspectable, j'en resterais à Phoenix 3
Typiquement dans quel type de projet/pour résoudre quel type de problème tu utilises Phoenix ?
Dès que j'ai besoin d'une fonction locale non nommé?
Partout où la PF peut amener une solution plus élégante?
Un ptit exemple sous la main ?
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 ?
vu que les 2 cree un foncteur temporaire contenant le code inliné, non.
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
Répondre avec citation
Partager