🔝 Retour au Sommaire
Le comité de standardisation C++ produit un volume de documentation considérable. Chaque cycle de réunion (trois par an) s'accompagne d'un mailing contenant des dizaines, parfois plus d'une centaine de papers. Sur un cycle triennal complet, cela représente plusieurs centaines de documents — proposals de fonctionnalités, rapports de Study Groups, corrections de wording, analyses de design, rapports de National Body, documents administratifs.
Personne, pas même les membres les plus actifs du comité, ne lit l'intégralité de cette production. La clé d'un suivi efficace n'est pas l'exhaustivité mais le filtrage intelligent : identifier rapidement les papers qui concernent vos domaines d'intérêt, comprendre leur statut dans le processus, et suivre leur évolution dans le temps. Cette section fournit les sources, les outils et les méthodes pour y parvenir.
Le site open-std.org est le dépôt officiel de tous les documents du comité WG21. C'est la source de vérité — chaque paper, chaque draft du standard, chaque compte rendu de réunion y est publié. Le site est maintenu par les organismes de standardisation et l'accès est entièrement gratuit.
La page principale des papers WG21 se trouve à l'adresse open-std.org/jtc1/sc22/wg21/docs/papers/. Les documents y sont organisés par année et par mailing :
- Chaque année contient deux à trois mailings, correspondant aux réunions du comité.
- Chaque mailing est une liste de papers publiés avant ou après la réunion (pre-meeting mailing et post-meeting mailing).
- Les papers sont listés par numéro (Pnnnn) avec leur titre, leur(s) auteur(s), et un lien vers le document (PDF ou HTML).
Le site est fonctionnel mais austère — c'est une liste de liens, sans moteur de recherche intégré, sans filtrage par thème et sans indication du statut d'avancement d'un paper. C'est la raison pour laquelle des outils complémentaires sont indispensables.
Le working draft est le brouillon en cours du prochain standard. C'est le document de référence qui reflète l'état actuel du texte normatif, incluant toutes les fonctionnalités votées jusqu'à la dernière réunion plénière. Le working draft le plus récent est toujours accessible sur open-std.org sous la forme d'un N-paper (par exemple N4971 pour un draft récent de C++26).
Pour les développeurs, le working draft est utile dans deux situations : vérifier le comportement exact d'une fonctionnalité quand la documentation informelle est ambiguë, et consulter le texte normatif quand on pense avoir trouvé un bug de compilateur. En dehors de ces cas, les papers individuels et les sources secondaires sont plus accessibles.
Les mailings sont publiés selon un calendrier prévisible, environ un mois avant et un mois après chaque réunion plénière. Cela donne six mailings par an, soit un flux régulier mais gérable. Le mailing pre-meeting est particulièrement intéressant car il contient les papers qui seront discutés lors de la prochaine réunion — c'est l'endroit où apparaissent les nouvelles proposals et les révisions significatives.
Une approche efficace consiste à consulter chaque pre-meeting mailing à sa publication, parcourir les titres, et ne lire en détail que les papers qui touchent à vos domaines d'intérêt. Ce tri prend rarement plus de 15 à 20 minutes et suffit à maintenir une veille de qualité.
Le comité utilise de plus en plus GitHub comme plateforme de travail collaboratif. Le dépôt github.com/cplusplus/papers est le point central : il héberge les issues liées aux papers en cours de discussion, les commentaires des membres du comité, et les liens vers les révisions successives des proposals.
L'avantage de GitHub par rapport à open-std.org est la dynamique : on peut voir les discussions en temps réel, les objections soulevées, les réponses des auteurs, et l'évolution du consensus. C'est une fenêtre sur le processus de délibération qui est invisible dans les papers publiés sur open-std.org, où seul le résultat final (le paper révisé) apparaît.
Utilisation pratique : surveillez les issues du dépôt cplusplus/papers. L'onglet Issues, filtré par labels, permet de suivre les discussions par domaine. L'outil "Watch" de GitHub permet de recevoir des notifications pour les nouvelles issues ou pour les discussions sur des issues spécifiques.
Le dépôt github.com/cplusplus/draft contient le code source LaTeX du working draft du standard. Pour le développeur, son intérêt principal est double :
- Les pull requests montrent en temps réel les modifications apportées au texte du standard après chaque vote. Quand une fonctionnalité est votée en session plénière, le wording correspondant apparaît sous forme de PR dans ce dépôt, souvent dans les jours qui suivent.
- L'historique des commits permet de retracer l'évolution exacte du texte normatif pour une fonctionnalité donnée, ce qui est utile quand on cherche à comprendre un changement de comportement entre deux versions d'un compilateur.
Certaines proposals majeures ont leur propre dépôt GitHub où le design est discuté publiquement. Ces dépôts sont particulièrement riches en informations car ils contiennent les discussions de design, les benchmarks, les implémentations de référence, et les retours des early adopters. Quelques exemples notables :
- Le dépôt de
std::execution(P2300) a accueilli des années de discussion sur le modèle Senders/Receivers avant l'intégration en C++26. - Les proposals de réflexion statique ont été accompagnées d'implémentations expérimentales dans des forks de Clang, avec des dépôts publics permettant de tester les fonctionnalités.
- La proposal de Pattern Matching a évolué à travers des discussions GitHub publiques où la communauté a pu fournir des retours sur la syntaxe et les cas d'usage.
Quand vous identifiez une proposal qui vous intéresse, recherchez si elle dispose d'un dépôt GitHub dédié — c'est souvent la source d'information la plus riche et la plus à jour.
Les sources primaires (open-std.org, GitHub) sont exhaustives mais brutes. Plusieurs outils et sources secondaires facilitent considérablement le suivi.
Le service wg21.link fournit des URLs courtes pour accéder directement à n'importe quel paper du comité. La syntaxe est triviale :
wg21.link/p2300mène directement à la dernière révision de P2300 (std::execution)wg21.link/p2996mène à P2996 (réflexion statique)wg21.link/n4971mène au working draft N4971
C'est l'outil à mettre en favoris. Quand un article de blog ou un trip report mentionne un numéro de paper, wg21.link/pXXXX est le moyen le plus rapide d'accéder au document.
Le site isocpp.org est le portail officiel de la communauté C++ standard. Il publie des news sur le langage, des résumés des évolutions du standard, et agrège des articles de blog de la communauté. Sa section "News" est un point d'entrée accessible pour les développeurs qui ne veulent pas plonger dans les papers techniques.
Le blog d'isocpp.org publie aussi les annonces post-réunion du comité, qui résument les décisions principales de chaque session plénière en quelques paragraphes. C'est le format le plus condensé pour rester informé.
Chaque compilateur majeur maintient une page de suivi de l'implémentation des fonctionnalités du standard :
- GCC : gcc.gnu.org/projects/cxx-status.html
- Clang : clang.llvm.org/cxx_status.html
- MSVC : documentation Microsoft sur le support des standards C++
Ces pages sont essentielles pour répondre à la question pratique : "La fonctionnalité X du standard Y est-elle utilisable avec mon compilateur actuel ?" Elles indiquent pour chaque feature le numéro du paper correspondant, la version du compilateur qui l'implémente, et parfois des notes sur les limitations de l'implémentation.
Le site cppreference.com maintient également un tableau comparatif du support compilateur pour chaque fonctionnalité, souvent plus à jour et plus lisible que les pages des compilateurs eux-mêmes.
Bien que ce ne soit pas un outil de suivi des proposals à proprement parler, cppreference.com mérite une mention spéciale. C'est la documentation de référence la plus utilisée par les développeurs C++ au quotidien — plus accessible que le texte normatif, plus fiable que la plupart des tutoriels, et remarquablement à jour. Chaque page indique le standard dans lequel une fonctionnalité a été introduite et le numéro du paper correspondant, ce qui facilite la traçabilité.
Pour les fonctionnalités récentes (C++23, C++26), cppreference.com est souvent la première source à documenter le comportement et l'API de manière lisible, parfois avant même que les compilateurs n'implémentent la fonctionnalité.
Le subreddit r/cpp (voir section 48.4.2) est un agrégateur de fait pour l'actualité du comité. Les mailings y sont discutés à chaque publication, les trip reports y sont partagés, et les proposals controversées y font l'objet de débats animés. Suivre r/cpp suffit souvent à rester informé de l'essentiel sans consulter directement open-std.org.
Quelques membres actifs de la communauté publient aussi des résumés commentés des mailings — des articles qui parcourent le contenu d'un mailing et mettent en lumière les papers les plus intéressants ou les plus significatifs. Ces résumés sont un filtre communautaire précieux, équivalent à un "curator's pick" appliqué aux documents du comité.
Les papers du comité ne sont pas des articles de blog. Ils sont rédigés dans un style technique, souvent dense, et leur structure répond à des conventions spécifiques. Voici comment les aborder sans y passer des heures.
Un paper typique contient les sections suivantes (avec des variations selon les auteurs) :
- Abstract / Introduction — Le résumé du problème et de la solution proposée. C'est la section à lire en premier, et parfois la seule nécessaire pour comprendre l'essentiel de la proposal.
- Motivation — Pourquoi cette fonctionnalité est nécessaire. Les exemples de code montrant les limitations actuelles et comment la proposal les résout sont souvent la partie la plus éclairante.
- Design — Les choix de design, la syntaxe proposée, le comportement spécifié. C'est le cœur technique du paper.
- Alternatives Considered — Les autres approches envisagées et les raisons de leur rejet. Cette section est précieuse pour comprendre les compromis.
- Impact on the Standard — Les modifications nécessaires au texte normatif existant.
- Implementation Experience — Les retours d'implémentations expérimentales (dans des forks de compilateurs, des librairies standalone, etc.). Quand cette section existe, elle est un indicateur fort de la maturité de la proposal.
- Proposed Wording — Le texte normatif exact à intégrer dans le standard. C'est la section la plus technique et la moins accessible pour un développeur non familier avec le style du standard.
Pour un suivi de veille, la lecture de l'Abstract, de la Motivation et des Alternatives Considered suffit dans la grande majorité des cas. Cela prend 5 à 15 minutes par paper et donne une compréhension solide de ce que la proposal vise et pourquoi. Le Design détaillé et le Proposed Wording ne sont nécessaires que si vous avez besoin de comprendre le comportement exact de la fonctionnalité — ce qui est rarement le cas avant que l'implémentation compilateur ne soit disponible.
Quelques indicateurs permettent d'évaluer rapidement où en est une proposal dans le processus :
- Numéro de révision élevé (R5, R7, R10…) — La proposal a été révisée de nombreuses fois, signe qu'elle est activement discutée et affinée. Les proposals à R0 ou R1 sont souvent des idées initiales encore loin de l'intégration.
- Mention d'implémentation — Si le paper cite une implémentation expérimentale dans GCC, Clang ou MSVC, la proposal est techniquement faisable et a été testée en pratique.
- Target standard explicite — Certains papers mentionnent explicitement le standard visé ("Targeting C++29"). C'est un indicateur de la timeline que les auteurs envisagent.
- Polls favorables — Les papers mentionnent parfois les résultats de votes en EWG/LEWG ("The poll to forward to CWG passed with strong consensus"). Ces résultats indiquent le niveau de support au sein du comité.
Voici une méthode concrète pour intégrer le suivi des proposals dans une routine de veille, adaptée au niveau 2 d'engagement décrit en section 48.3.
- Consultez la liste des papers du mailing sur open-std.org ou attendez qu'un résumé commenté soit publié sur r/cpp ou un blog spécialisé.
- Parcourez les titres et identifiez les papers qui touchent à vos domaines d'intérêt.
- Pour chaque paper retenu, lisez l'Abstract et la Motivation.
- Notez les numéros des papers à suivre pour les prochains mailings.
- Lisez un ou deux trip reports (recherchez "C++ committee trip report [date] [lieu]").
- Identifiez les proposals qui ont avancé, été votées dans le working draft, ou été rejetées.
- Mettez à jour votre liste de papers suivis.
- Surveillez les discussions sur les dépôts GitHub des proposals qui vous intéressent.
- Suivez r/cpp pour les discussions communautaires sur les proposals en cours.
- Regardez les talks de conférence qui présentent les proposals majeures (voir section 48.2).
Maintenez une liste simple (un fichier texte, un tableau, ou un outil de notes) des proposals que vous suivez, avec pour chacune : le numéro du paper, le sujet, le dernier statut connu, et la date de mise à jour. Ce suivi minimal transforme une veille passive en une base de connaissances personnelle qui prend de la valeur avec le temps.
| Source | URL | Contenu | Fréquence de consultation |
|---|---|---|---|
| open-std.org | open-std.org/jtc1/sc22/wg21/ | Papers officiels, mailings, working drafts | À chaque mailing (6x/an) |
| wg21.link | wg21.link | Accès rapide à n'importe quel paper | Au besoin |
| cplusplus/papers (GitHub) | github.com/cplusplus/papers | Discussions sur les proposals | Hebdomadaire si suivi actif |
| cplusplus/draft (GitHub) | github.com/cplusplus/draft | Working draft, PRs post-votes | Après chaque réunion |
| isocpp.org | isocpp.org | News, annonces, blog communautaire | Mensuelle |
| cppreference.com | cppreference.com | Documentation, support compilateur | Quotidienne (référence) |
| Pages support compilateurs | gcc.gnu.org, clang.llvm.org | État d'implémentation des features | Avant chaque adoption |
| Reddit r/cpp | reddit.com/r/cpp | Discussions, trip reports, résumés mailings | Hebdomadaire |
💡 Note : Le piège le plus courant du suivi des proposals est de confondre "paper publié" avec "fonctionnalité qui arrivera dans le prochain standard". La majorité des papers soumis au comité ne deviennent jamais des fonctionnalités standardisées — certains sont rejetés, d'autres fusionnés avec des proposals concurrentes, d'autres encore abandonnés par leurs auteurs. Ne planifiez jamais votre architecture sur la base d'une proposal qui n'a pas encore été votée dans le working draft. Jusqu'au vote plénier, rien n'est acquis. Après le vote, l'implémentation compilateur reste nécessaire avant l'utilisation en production. Cette discipline d'attente est le prix de l'anticipation responsable.