URL: https://linuxfr.org/users/rewind/journaux/c-17-est-sur-les-rails Title: C++17 est sur les rails Authors: rewind Date: 2016年03月12日T09:28:45+01:00 License: CC By-SA Tags: c++ et c++17 Score: 50 À la dernière réunion du comité de normalisation de C++ qui a eu lieu à Jacksonville (Floride), les fonctionnalités de C++17 ont été plus ou moins gelées. On sait désormais ce qu'il y aura dedans mais aussi ce qu'il n'aura pas dedans. Et ça crée pas mal de remous. Dans les nouveautés attendues : - une [API pour gérer le système de fichier](https://isocpp.org/files/papers/P0218r1.html) (basée sur Boost.Filesystem) - des [algorithmes parallèles](https://isocpp.org/files/papers/P0024R2.html) (ceux de la STL où on a ajouté un argument en premier pour dire qu'on veut qu'ils s'exécutent en parallèle) - plein de [petites classes utiles](https://isocpp.org/files/papers/p0220r1.html) qui étaient présentes dans Boost pour la plupart : `any`, `optional`, `string_view`; ainsi que des compléments à des trucs déjà existants - des fonctions mathématiques spéciales - la disparition de fonctionnalités obsolètes comme `auto_ptr` Et pleins d'autres petits trucs. Où est le problème alors ? Et bien, beaucoup de gens avaient de grands espoirs pour cette version de C++17. Il faut dire qu'elle avait été annoncée comme une version majeure de longue date : au moment de la publication de C++11, il avait été annoncé que C++14 serait une version mineure pour corriger C++11 (ce qu'elle a été) et que C++17 serait la prochaine version majeure avec une version mineure C++20. Et puis, dès le départ, [Bjarne Stroustrup](https://fr.wikipedia.org/wiki/Bjarne_Stroustrup), créateur du C++ et qui joue encore un rôle important dans le comité de normalisation, avait [annoncé la couleur](https://isocpp.org/files/papers/D4492.pdf). Il voulait : les modules, les contrats, le type `variant` (destiné à avoir un remplaçant mieux typé de union), une bibliothèque pour le réseau, des co-routines, de la [mémoire transactionnelle](https://fr.wikipedia.org/wiki/M%C3%A9moire_transactionnelle_logicielle), les concepts, une nouvelle STL basée sur les intervalles (Range), la syntaxe d'appel uniforme, etc. Et au final, rien de tout ça n'a été intégré à la version C++17. Les raisons sont variées mais la plupart du temps, les propositions n'étaient pas assez mûres : les modules ont deux implémentations très différentes et incompatibles pour l'instant (une de MS, une de Clang) ; le type `variant` a donné lieu à de très nombreux débats quant à savoir s'il fallait un état invalide (notamment par défaut) ou pas ; la bibliothèque réseau (basée sur Boost.asio) recoupe tout un tas de propositions (notamment sur la partie asynchone) qu'il faut finaliser ; les co-routines provoquent des guerres de religion pour savoir s'il faut une pile ou pas et disposent d'au moins 3 propositions dont aucune ne fait vraiment l'unanimité ; les concepts ne disposent pour l'instant d'aucune implémentation qui permettent de voir si la proposition est valide ; la nouvelle STL est basée sur les concepts ; la syntaxe d'appel uniforme ne fait pas du tout consensus à cause de problèmes intrinsèques importants. Pourtant, les plus gros morceaux parmi ces propositions ont été poussé dans des Spécifications Techniques (TS), qui sont une sorte d'antichambre officielle pour les futures fonctionnalités du C++. C'est d'ailleurs par là que sont passé les propositions qui ont été intégrées à C++17. Mais même avec ça, [la déception est grande](https://www.reddit.com/r/cpp/comments/49dgdb/why_i_am_not_happy_with_c17_c_17_outlook_march/). Certains ont pointé du doigt le comité de normalisation et son fonctionnement à l'ancienne, même s'il s'est beaucoup ouvert depuis 2011 et que tout le monde peut participer et faire des propositions. D'autres ont critiqué le fait que peu de gens sont salariés pour travailler sur la norme et les nouvelles propositions et que ça freine leur inclusion dans la norme. Pour répondre à tout ça, il a plus ou moins été décidé que la prochaine version sortirait en 2019 pour raccourcir un peu le délai entre deux versions. Mon avis d'utilisateur du C++, c'est qu'il y a eu beaucoup trop d'attente et pas assez de travail. Je préfère un comité de normalisation prudent, qui pèse bien toutes les conséquences que peut avoir une proposition sur l'ensemble du langage existant. Oui, on peut parfois être envieux des mécanismes qu'on peut voir sur des langages comme Rust, mais nous ne sommes pas dans le même contexte : Rust est encore très jeune et dynamique et peut se permettre des évolutions majeures rapides, C++ a une base de code énorme qu'il ne faut pas casser sans pour autant laisser le langage dans le formol. Les nouveautés annoncés pour C++17 me vont bien (Boost.Filesystem doit être la bibliothèque Boost que j'utilise le plus, de très loin), et pour le reste, on attendra que ça soit prêt (façon Debian).

AltStyle によって変換されたページ (->オリジナル) /