Sommaire
Dépêches C++
Chère lectrice, cher lecteur de LinuxFr.org. Tes collègues sont en vacances et tu cherches à t’occuper ? Ou alors, tu es en vacances et l’actualité informatique te manque déjà ? Eh bien, voici une première dépêche d’une longue série sur le C++. Ainsi, tu seras en avance technologique dès la rentrée.
Résumé des dépêches :
Cette première dépêche, Les coulisses du C++, présente la naissance du langage, puis du standard, sa spécification non libre, payant, ouvert, délaissé au profit de son brouillon (draft), peu lu par les développeurs C++, évoluant lentement mais sûrement…
La deuxième dépêche, Genèse du C++17, reviendra sur les dernières réunions du comité de normalisation.
La troisième dépêche, Nouveautés C++17 du langage, présentera des changements du langage très intéressants : déduction des arguments template std::array a{1,2,3};, décomposition du retour de fonction auto [x, y] = f(); , namespace aa::bb{} équivalent à namespace aa{ namespace bb{}}, if constexpr sélectionne du code à la compilation, lambda constexpr, lambda capture *this, if(init;condition) comme for(init;cond;inc), variables inline… Mais il faudra encore attendre pour l’intégration des Concepts, Modules, Syntaxe d’appel uniforme et Réflexion.
La quatrième dépêche, Nouveautés C++17 de la bibliothèque standard, présentera les changements au niveau de la bibliothèque standard qui pourraient bousculer notre petite vie de développeur : algorithmes parallélisés, std::string_view, std::filesystem, std::variant, std::any, std::optional, les fonctions spéciales mathématiques… Mais, les intervalles (ranges), le réseau (networking) seront intégrés pour une version ultérieure.
Bilan C++17 et attentes pour C++20. Version mineure ou majeure ? D’un côté, les améliorations sont nombreuses et appréciables. Mais de l’autre, aucune fonctionnalité majeure n’est intégrée, exceptées celles qui sont déjà disponibles dans Boost (donc déjà supportées par un large panel d’anciens compilateurs). Conséquences sur le processus de normalisation ? Qu’attendre de C++20 ? Intérêt du C++ aujourd’hui ? Et les langages alternatifs ? Comment s’impliquer ?
… d’autres dépêches à venir. :-)
Partage
Chère lectrice, cher lecteur LinuxFr.org. Tu souhaites donner un coup de main pour les dépêches suivantes ? Rejoins‐nous dans l’espace de rédaction collaborative sur LinuxFr.org. Un compte est nécessaire pour y accéder.
Après publication, les dépêches sont figées sur LinuxFr.org. Alors, pour continuer à améliorer ce contenu libre (fôtes, oublis, franglais, maladresses…), n’hésite à pas à aller sur le dépôt Git C++FRUG. C’est là aussi que tu trouveras les versions de ces dépêches les plus à jour :
-
Les coulisses du standard C++ ;
-
Genèse d’une version mineure ;
-
Nouveautés du langage ;
-
Nouveautés de la bibliothèque standard ;
-
Bilan et attentes pour C++20.
Avec toutes nos contributions réunies, nous profiterons davantage de nos découvertes individuelles et nous offrirons un contenu CC BY-SA de qualité pour créer, par exemple, un article Wikipédia C++17 en français. :-)
Naissance d’un nouveau langage
À la fin des années 70, dans la cadre de sa thèse en Angleterre, le Danois Bjarne Stroustrup étudiait le paradigme de la programmation objet (avec le langage Simula). En 1979, aux Laboratoires Bell (États‐Unis), Bjarne propose de rajouter ce paradigme objet au langage C qu’il appela « C with Classes ».
Durant les années 80, les nouvelles fonctionnalités qui sont progressivement intégrées au tout nouveau C++ provoque un schisme entre les fans du C classique et les enthousiastes du C++.
Création du comité de normalisation C++
Dans la seconde moitié des années 80, le usenet comp.lang.c++ bouillonne, les premiers compilateurs C++ commencent à diverger, les développeurs ont du mal à écrire du C++ portable et dix ans après la création du C with Classes, des événements majeurs se produisent :
- avril 1989, le groupe de travail WG14 (comité du C) souhaite une normalisation du C++ ;
- mai 1989, à la demande du WG14, Andrew Koenig et Bjarne Stroustrup rédigent C++: as close as possible to C — but no closer, pour expliquer les divergences (incompatibilités) du C++ par rapport au C (ce qui est valide en C et qui ne l’est pas en C++) ;
- juillet 1989, Dmitry Lenkov explique la création d’un groupe de travail C++ officiel et d’y inclure d’office Bjarne Stroustrup ;
- février 1990, première réunion du comité ANSI C++ ;
- juin 1991, la réunion du comité ANSI C++ réunit de très nombreux participants non états‐uniens et la décision est prise de travailler conjointement avec le groupe de travail WG21 international.
La puissance du C++
En 1991, un nouveau paradigme, la programmation générique (template) est ajouté, ainsi que les exceptions.
Le C++ devient alors un formidable langage alliant un découplage puissant et la performance du code exécutable optimisé par les compilateurs C adaptés (cette flexibilité est très bien illustrée dans l’excellent journal Expressions template pour les nuls de serge_sanspaille_). Mais cette compatibilité avec le langage C contraint à utiliser une grammaire pas toujours simple et un temps de compilation souvent long.
En 1994, Erwin Unruh présente au comité C++ un code source qui permet de calculer les nombres premiers à la compilation. Pour une partie des membres du comité, c’était une curiosité. Tandis que les autres membres se grattaient la tête et prirent conscience que l’on venait de découvrir, par hasard, que les templates du C++ permettaient le paradigme de la métaprogrammation !
Cette découverte ouvre la voie à d’extraordinaires optimisations en permettant au compilateur de réaliser des calculs à la compilation (à ne pas confondre avec la réalisation de calculs à l’initialisation ou durant l’exécution). Ces techniques atteignent des sommets avec boost::mpl (2002), boost::proto (2008) et le futur boost::simd.
Au détriment d’une grammaire difficile, des erreurs faciles, d’une compilation lente et d’un débogage laborieux. Mais c’est un des rares langages qui offre au développeur autant d’abstraction et de performance en même temps. La passion de ce langage l’emporte. Avec le temps, les pièges sont connus, les techniques maîtrisés, et le C++ devient un vrai bonheur. :-)
De plus, ce langage bien vivant continue d’évoluer dans le bon sens. Les très nombreux outils qui orbitent autour de ce formidable langage continuent aussi d’apporter plein de nouvelles fonctionnalités. :-D
Les membres du comité de normalisation
En 1998, les membres finalisent le premier standard C++ : C++98. Soit une vingtaine d’années après la création du langage, et une dizaine d’années après l’initiative de normaliser celui‐ci.
Pour devenir membre du comité international de normalisation du C++, appelé officiellement ISO/IEC JTC 001/SC 22/WG 14/WG 21, il faut être membre d’une représentation ISO de son pays. Une dizaine de pays est représentée :
C’était IBM qui payait les frais de représentation du Comité de Normalisation Cpp de l’AFNOR. Mais, au départ à la retraite des employés IBM membres C++, plus personne ne payait les frais de représentation et la France n’était plus officiellement représentée. Depuis peu, les choses sont rentrés dans l’ordre.
Une centaine de membres actifs se rencontrent quelque fois par an dans le cadre de la normalisation du C++ (essentiellement pour voter). Le plus gros du travail se fait à distance. Les membres C++ et les autres passionnés du C++ se rencontrent également lors des grandes rencontres du C++ : CppCon, C++Now, Meeting C++…
Dans l’intérêt des utilisateurs du C++, les membres du comité accordent au comité et à l’ISO une licence mondiale, non exclusive, irrévocable, permettant l’octroi d’une sous‐licence transférable pour l’affichage du contenu, la reproduction, l’adaptation, la distribution, la création de travaux dérivés à des fins commerciales ou non commerciales. En 2012, cette règle a notamment été rappelée à IBM, Intel et Oracle (voir N3423 §2.4).
Le standard ne peut être reproduit
Comme la plupart des documents publiés par l’ISO, la mention de droit d’auteur indique que la reproduction n’est pas autorisée :
© ISO/IEC 2014 — All rights reserved
COPYRIGHT PROTECTED DOCUMENT
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
Cette position est la même pour les autres langages gérés par l’ISO (Fortran, C…). Mais aussi pour Java, C# et de nombreux autres.
Dans la pratique, cela ne gène pas les développeurs de ces langages. Ce type de mention empêche juridiquement la reproduction du standard (même un paragraphe ou un code d’exemple). Des sites qui respectent à la lettre le droit d’auteur, comme Wikipédia, refusent de contenir la reproduction même partielle d’un tel document. D’autres sites, comme stackoverflow, sont plus pragmatiques.
Notons que d’autres langages de programmation ont des spécifications libres :
Le standard est payant
De plus, obtenir le standard C++ coûte cher. Même la version PDF téléchargée :
(voir aussi d’autres sites vendant le standard)
Les anciens standards supprimés
Encore plus incroyable : chaque nouvelle publication du standard révoque ou supprime (withdraw) la version précédente :
L’embêtant est que la plupart des projets C++ actuellement utilisés sont codés en C++03. Et la plupart des entreprises utilisent encore aujourd’hui des versions de compilateurs qui ne supportent pas (ou partiellement) le standard C++11.
Alors, comment s’informer du standard C++ utilisé par le bon vieux compilateur que l’on est obligé d’utiliser ? Aller les consulter à l’INRIA ? Par exemple, cet utilisateur a besoin d’acheter le standard C++03 qui n’est plus à la vente.
Ouf, les brouillons du comité
Les documents en cours de rédaction (draft) du comité de normalisation sont gratuitement accessibles :
Quand le comité de normalisation C++ valide un brouillon (nouvelle version C++), ce brouillon bénéficie de dernières corrections. Puis, le comité le fournit à l’ISO qui change la mise en forme pour en faire une version officielle.
Documentations C++ de référence
Les standards C++ (officiels ou brouillons) ne sont pas simples à lire. Ces documents utilisent une terminologie très spécifique pour une spécification très rigoureuse. En fait, ces documents sont surtout utiles aux développeurs des compilateurs et à ceux qui implémentent des bibliothèques standards (std::).
Les utilisateurs du C++ (langage et bibliothèque standard) utilisent historiquement des livres (souvent ceux écrits par Bjarne Stroustrup et Scott Meyers) et plus récemment des sites Web :
Un standard ouvert
Note des auteurs de cette dépêche : Nous avons un profil plutôt technique (développeurs) et non pas juriste. Ce chapitre contient peut‐être des erreurs importantes, mais nous avons tenté de rédiger ce qui nous semble correct… Nous n’avons pas pris le risque de nous aventurer à comparer C++ avec Java, C#… Celles et ceux qui connaissent bien le sujet, merci de nous éclairer dans les commentaires. :-)
Le C++ est bien un standard ouvert, sans brevet logiciel, sans propriété intellectuelle. C’est‐à‐dire que le langage et sa bibliothèque standard (API) peuvent être implémentés librement.
De même, le nom C++ n’est pas une marque, ni aucun type de propriété intellectuelle. À la différence de la marque JavaScript® déposée par Oracle, ou des marques non déposées Rust™, Go™ (et une autre Go™).
Et, même si C++ n’est pas encore aussi ouvert que peut l’être Rust™, de nombreux membres du comité améliorent constamment la façon de travailler pour plus de transparence et plus de proximité avec les utilisateurs C++, comme l’utilisation d’un compte GitHub.
Les versions C++
Même si le langage naît à la fin des années 1970, il n’est normalisé que vingt ans plus tard, afin d’arrêter la profusion de versions C++ incompatibles.
Le tableau suivant liste les différentes versions C++ normalisées, ainsi que le brouillon C++17 en cours de consolidation. Nous pouvons remarquer le saut considérable du nombre de pages entre C++03 et C++11.
Attention, ce dernier lien est celui du brouillon C++17 le plus récent lors de la rédaction de cette dépêche. Cette version sera certainement obsolète quelques mois après la publication de cette dépêche.
Ceux qui ont l’œil aiguisé remarqueront que le brouillon N3376 représentant la version C++11 a été publiée (28/02/2012) après la norme officielle 14882:2011 (1/09/2011). Ce N3376 correspond en fait à des corrections éditoriales mineures apportées au brouillon N3291 fourni à l’ISO. C’est le premier brouillon de post‐publication, le first post‐publication draft en anglais.
Technical Specification (TS)
Les spécifications techniques, notées TS pour Technical Specification, sont les documents de travail les plus importants du comité de normalisation. Ces documents sont la base de discussion des évolutions du standard.
Généralement, les spécifications techniques sont composées de deux parties :
- la première partie donne les motivation du changement (l’avantage d’avoir telle fonctionnalité dans le C++ avec des exemples de code) ;
- la seconde partie liste toutes les modifications à appliquer au standard C++ en cours de rédaction (au draft).
Numérotation des documents
À partir de 1990, le comité numérote ses documents officiels sur quatre chiffres en commençant par le n°0000. Ce numéro est incrémenté pour chaque nouveau document ou nouvelle révision d’un document.
En 1991, le préfixe N est adoptée, et le premier document à en profiter est le N0007. N comme Number (numéro).
Ces numéros xxxx peuvent paraître obscurs, mais sont très importants, car ils sont utilisés comme références rigoureuses aux fonctionnalités C++ :
- dans les échanges entre membres du comité ;
- par de nombreux sites Web.
Pour faire le lien entre les principales spécifications techniques (TS) et leur numéro xxxx de révision la plus récente, une astuce est d’utiliser la page experimental sur cppreference.com.
Voici, en exemple, l’historique des TS à propos des Modules :
| Année |
Numéro |
Titre |
Révision |
| 2004 |
N1736 |
Modules in C++ |
1 |
| 2005 |
N1778 |
Modules in C++ |
2 |
| 2006 |
N1964 |
Modules in C++ |
3 |
| 2006 |
N2073 |
Modules in C++ |
4 |
| 2007 |
N2316 |
Modules in C++ |
5 |
| 2012 |
N3347 |
Modules in C++ |
6 |
| 2014 |
N4047 |
A Module System for C++ |
1 |
| 2014 |
N4214 |
A Module System for C++ |
2 |
| 2015 |
N4465 |
A Module System for C++ |
3 |
| 2016 |
P0142R0 |
A Module System for C++ |
4 |
Remarquons le changement de nommage pour la révision de 2016. Le nouveau nommage PxxxxRx a été mis en place en septembre 2015 avec un P comme Proposal (Proposition). Progressivement, les PxxxxRx doivent remplacer les Nxxxx. L’avantage est de conserver le même numéro xxxx pour toutes les révisions du document.
Comme en C++, on commence par compter la première Révision à partir de R0. L’exemple ci‐dessus est un cas particulier : R0 est bien la première révision du nouveau format, mais la quatrième révision des documents A Module System for C++.
Defect Report (DR)
Même après moult relectures par les meilleurs experts C++ au monde, avec toutes les précautions prises par les institutions officielles, les publications des standards C++ contenaient 5 000 anomalies ayant fait l’objet, chacune, d’un rapport d’anomalie (Defect Report) !
Lors de ses réunions, le comité discute des rapports d’anomalie et devrait publier régulièrement des rectificatifs techniques (Technical Corrigendum). Mais le comité n’a jamais publié aucun rectificatif technique à ce jour !
Par exemple, le comité avait approuvé un rectificatif technique en 2003. Et, finalement, le comité publie comme étant une nouvelle version du standard, le C++03 :
A technical corrigendum was approved in 2003, and the standard was published again as the ISO/IEC 14882:2003 edition, published 2003-10-16.
Bon, c’est vrai, à la décharge du comité, ce rectificatif technique de 2003 contenait une nouvelle fonctionnalité : Value initialization. C’était la dernière fois, que le comité avait travaillé sur un rectificatif technique.
Néanmoins, même si le comité ne publie aucun rectificatif technique, les rapports d’anomalie approuvés doivent être pris en compte par les compilateurs. Des sites comme cppreference.com listent les changements induits par ces rapports d’anomalie :
Les versions officielles du C++ deviennent donc vite obsolètes après leur publication, car ces documents sont figés et ne bénéficient pas des corrections apportées par les rapports d’anomalie. Par conséquence, celui qui achète une version officielle du standard C++, devrait aussi suivre tous les rapports d’anomalie approuvés par le comité…
Pour terminer, notons aussi que des rapports d’anomalie approuvés lors d’une réunion du comité se retrouvent ne plus être approuvés lors de la réunion suivante.
Alors, chère lectrice, cher lecteur de LinuxFr.org, es‐tu étonné(e) par ce fonctionnement. Connais‐tu d’autres façons de maintenir un tel document ? Comment cela se passe‐t‐il dans d’autres langages de programmation ? As‐tu des idées d’amélioration ?
Un langage compliqué qui se simplifie
Par rapport à tous les langages utilisés en production, avouons que le C++ est peut‐être le langage le plus complexe que l’humanité ait pu inventer ! Les développeurs C++ en ont bien conscience. C’est peut‐être la raison pour laquelle les participants aux meetups se montrent souvent bienveillants à l’égard des autres langages. Les développeurs C++ aimeraient un langage plus simple, à condition de « ne pas sacrifier la sacro‐sainte performance ».
Le C++ est tellement vaste et semé de subtilités, que les développeurs C++ n’en connaissent bien souvent qu’une petite portion. Ainsi, lors d’un entretien de Bjarne Stroustrup (un des experts C++ les plus actifs du comité), celui‐ci avait indiqué qu’il connaissait seulement 60 % du standard. Ceux qui maîtrisent vraiment le C++ sur le bout des doigts sont appelés des juristes du C++, ou plus généralement « language lawyers » en anglais (ils ne sont pas forcément de bons développeurs).
Pour inverser la tendance, certains membres du comité de normalisation, comme Bjarne Stroustrup (le créateur du C++) souhaitent accélérer l’évolution du langage vers un C++ plus intuitif, plus sûr, et toujours plus performant.
Un processus de normalisation qui s’ouvre davantage
C’est dans ce cadre que l’initiative C++ Core Guidelines (Recommandations C++) a été lancée. A la fois pour proposer un sous‐ensemble du C++ plus sûr, plus simple et sans sacrifier les performances. Mais aussi pour faire pression sur les membres du comité pour adopter les idées de la Guidelines Support Library (Bibliothèque de support des recommandations) activement implémentée sur le dépôt Git de Microsoft, mais aussi sur le dépôt Git de Martin Moene qui est compatible avec beaucoup plus de compilateurs.
Pour faciliter les contributions au standard, le comité a aussi migré sur GitHub. Le standard en cours de rédaction/maintenance est sur le dépôt Git draft (brouillon). L’intégration d’une fonctionnalité au brouillon (standard en cours de rédaction) est souvent formalisée par une fusion (merge) d’une branche Nxxxx vers la branche master.
Cycle de publication triannuel
Après la version majeure C++98 (et son correctif C++03), un nouveau standard C++ devait être publié dans les années suivantes. Comme sa date de publication n’était pas fixée, cette version a été nommée temporairement C++0x.
Mais, avec le manque de maturité de certaines fonctionnalités et les requêtes continuelles d’ajout de nouvelles fonctionnalités, le comité de normalisation n’arrivait pas à stabiliser le standard. Et, finalement, C++0x a été publié en 2011 ! Ne perdons pas la face, 0x = 11 est correct mathématiquement avec x = B en hexadécimal :-)
Afin d’éviter tout nouveau glissement, le comité a alors décidé de publier un nouveau standard C++ tous les trois ans, en figeant les fonctionnalités l’année n - 1. Avec un cycle d’une version majeure (C++11) suivie d’une version mineure (C++14).
Malgré des dates de publication figées, les appellations C++1y (pour C++14) et C++1z (pour C++17) perdurent. Par exemple, l’option de compilation -std=c++1z ou l’étiquette c++1z sur stackoverflow.
Les membres du comité de normalisation utilisent le terme C++17 (et non pas C++1z). Soyons confiants, C++1z verra bien le jour en 2017 (et non pas en 2018, ni après).
Implémentation de référence
Le comité ne fournit pas plus d’implémentation de référence ou de preuve de concept. Mais les membres du comité travaillent en étroite collaboration avec les éditeurs de compilateurs (notamment GCC et LLVM/Clang).
Néanmoins, en 1999, des membres du comité ont quand même créé le projet Boost.org afin de proposer et valider des implémentations de fonctionnalités candidates de la bibliothèque standard. Ainsi, dès 2005, la publication du brouillon C++ TR1 est en lien direct avec les développements fournis par le projet Boost.org.
D’ailleurs, c’est devenu le parcours classique pour les nouveaux composants de la bibliothèque standard. C’est, par exemple, le cheminement de std::filesystem. Et plus récemment, quand le Français Joël Falcou a proposé la fonctionnalité SIMD, les membres du comité l’ont invité à intégrer Boost dans un premier temps. Cela permet également de vérifier la popularité d’un composant.
La suite…
La prochaine dépêche va nous permettre d’entrer enfin dans le vif du sujet C++17.
Merci de nous donner un coup de main à la rédaction des prochaines dépêches C++17. Pour participer ou lire en avance les prochaines dépêches :
Droit d’auteur, remerciements et licences
Le texte de cette dépêche est protégé par le droit d’auteur la gauche d’auteur et réutilisable sous licence CC BY-SA 4.0. Merci aux nombreux auteurs sur le dépôt Git et sur LinuxFr.org : olibre, duckie, rom1v, Oliver H, cracky, Lucas, palm123, Adrien Dorsaz, Martin Peres, RyDroid, M5oul, Anthony Jaguenaud et Benoît Sibaud. Merci aussi à Klaim, Édouard A, rewind, David Demelier, gasche, freem et ®om pour leurs commentaires pertinents.
Aussi un immense merci à mes collègues développeurs qui, à défaut de m’aider à la rédaction, ont illustré cette dépêche (et les dépêches suivantes) avec des dessins humoristiques sous licence libre : Ziyue, AKP, Florent B, et Jae-Zun. Merci aussi à Dominic Alves pour son dessin C++ sous licence libre. Merci à Theppitak Karoonboonyanan pour maintenir la police de caractères Purisa.
Merci d’avance de l’aide apportée sur les prochaines dépêches C++17 en cours de préparation : Micka pour ses exemples utiles et AMB007 pour les bogues trouvés dans les codes C++ d’exemple.
