C++26 est finalisé ! — la plus grande mise à niveau depuis C++11, avec validation officielle de la réflexion et du renforcement de la sûreté mémoire

(herbsutter.com)

22 points par GN⁺ 2026-03-31 | 7 commentaires | Partager sur WhatsApp

C++26 est officiellement finalisé sur le plan technique. Il inclut quatre fonctionnalités clés : la réflexion, le renforcement de la sûreté mémoire, les contrats (Contracts) et std::execution
La réflexion à la compilation constitue le moteur d’abstraction le plus puissant de l’histoire de C++ depuis l’introduction des templates, permettant au langage de se décrire lui-même et de générer du code
Le simple fait de recompiler un code C++ existant en C++26 supprime toute une catégorie de comportements indéfinis (UB) liés aux variables locales non initialisées, tandis que la bibliothèque standard renforcée garantit la sûreté des limites
D’après les déploiements chez Google, plus de 1 000 bugs ont été corrigés et le nombre de segfaults en production a baissé de 30 %
On s’attend à une adoption rapide par les compilateurs, GCC ayant déjà fusionné la réflexion et les contrats dans sa branche trunk

C++26 est finalisé : la version la plus importante depuis C++11

Lors de la réunion du comité ISO C++ à Croydon, Londres, au Royaume-Uni, le travail technique sur C++26 a été achevé définitivement
- Environ 210 participants (130 en présentiel, 80 à distance via Zoom), avec des représentants officiels de 24 pays
- L’essentiel de la réunion a été consacré au traitement de 411 commentaires internationaux (étape CD) reçus durant l’été
- Aucun ajout ni retrait de fonctionnalité : l’accent a été mis sur les finitions et le polissage
C++26, finalisé lors de cette réunion, entre désormais dans la phase de rédaction du document final en vue du vote d’approbation internationale (DIS)

Les 4 fonctionnalités majeures de C++26

(1) Réflexion (Reflection)

Il s’agit de la plus grande évolution de l’histoire du développement C++ depuis l’invention des templates : le langage peut se décrire lui-même et générer du code
En juin 2025, le comité C++ a inclus la réflexion à la compilation dans le projet C++26, marquant un tournant dans l’histoire du langage
Elle est présentée comme « le nouveau moteur le plus puissant pour exprimer des abstractions efficaces, et il faudra probablement dix ans pour découvrir tout ce que cette fusée peut accomplir »

(2) Renforcement de la sûreté mémoire

Le simple fait de recompiler un code C++ existant en C++26 élimine toute la catégorie d’UB (comportements indéfinis) liée à la lecture de variables locales non initialisées
La bibliothèque standard renforcée (Hardened Standard Library) est standardisée et garantit la sûreté des limites pour des types majeurs comme vector, span, string et string_view
- Le surcoût de performance mesuré est en moyenne de 0,3 % (moins de 1 %)
- Elle est déjà déployée sur des centaines de millions de lignes de code chez Apple et dans des services Google
Chiffres issus du déploiement chez Google :
- Plus de 1 000 bugs corrigés
- Prévision de 1 000 à 2 000 bugs évités par an
- 30 % de réduction du taux de segfaults sur l’ensemble de la production
- Sur tout le code C++ de Google, seuls 5 services ont demandé un opt-out complet, et seulement 7 endroits utilisent encore des API d’accès non sûres

(3) Contrats (Contracts) : pre, post, `contract_assert`

C++26 introduit des contrats au niveau du langage — prise en charge des préconditions (precondition), postconditions (postcondition) et de l’instruction d’assertion
Cette fonctionnalité est jugée bien plus puissante que la macro assert du C
Résultats des votes sur l’adoption des contrats :
- Février 2025 (fusion dans le working draft) : 100 pour, 14 contre, 12 abstentions
- Mars 2026 (validation finale de C++26) : 114 pour, 12 contre, 3 abstentions
Des inquiétudes techniques ont persisté chez certains experts du comité, mais elles ont été largement discutées au cours de trois réunions et de nombreux appels
Avant la réunion de novembre 2025, deux bugs de la spécification des contrats avaient déjà été corrigés à partir des retours reçus

(4) `std::execution` (Sender/Receiver)

Il s’agit du modèle asynchrone de C++, un framework unifié pour exprimer et contrôler la concurrence et le parallélisme
Il permet d’écrire facilement de la structured concurrency (concurrence à durée de vie strictement imbriquée), avec des propriétés de sûreté qui empêchent structurellement les data races
Attention : la documentation reste insuffisante et les bibliothèques « fingers-and-toes » sont encore peu développées, ce qui rend son adoption plus difficile que pour d’autres fonctionnalités C++
- Il peut être nécessaire de se faire aider par des experts déjà familiers du sujet et d’écrire des bibliothèques d’adaptation pour l’interopérabilité avec du code asynchrone existant

Pourquoi une adoption rapide de C++26 est attendue

Il s’agit de l’ensemble de fonctionnalités le plus attendu depuis C++11, avec la réflexion et le renforcement de la sûreté qui seront utilisés au quotidien par la majorité des développeurs C++
- À l’inverse, le Parallel STL, les concepts, les coroutines ou les modules de C++17, C++20 et C++23 n’ont pas eu un impact aussi large que C++11 sur l’ensemble des développeurs C++
GCC et Clang ont maintenu, tout au long du développement de C++26, une pré-implémentation d’environ deux tiers des fonctionnalités
- GCC a déjà fusionné la réflexion et les contrats dans trunk, en attente de publication

Début des travaux sur C++29 : approfondir la sûreté mémoire

Lors de cette réunion, le calendrier de C++29 a également été adopté, confirmant le cycle de publication sur trois ans
L’objectif principal de C++29 est déjà fixé : renforcer davantage la sûreté des types et de la mémoire
- Des propositions visant à réduire encore les comportements indéfinis (UB) sont en cours d’examen
- Le SG23 (sous-groupe sûreté/sécurité) travaille à partir du profil de sûreté des types P3984 de Bjarne Stroustrup et du framework de profils génériques de Gabriel Dos Reis
Oliver Hunt d’Apple a présenté P4158R0 « C++ Subsetting and Restrictions for Memory Safety »
- Une approche subset-of-superset a été appliquée à plus de 4 millions de lignes de code de WebKit
- Selon le rapport, elle bloque « de nombreuses classes de vulnérabilités, et la politique actuelle aurait empêché la plupart des exploits passés »
Le thème de la sûreté mémoire a été débattu en profondeur lors de la session du mercredi soir, à laquelle participait plus de la moitié du comité, ainsi que lors d’une session EWG dédiée le vendredi après-midi avec environ 90 participants
La bibliothèque des quantités et unités (P3045R7 "Quantities and units library") est passée des groupes SG6 et SG18 au LEWG (sous-groupe principal d’évolution de la bibliothèque)

Prochain calendrier

Les deux prochaines réunions sont prévues à Brno, en République tchèque (juin) et à Búzios, près de Rio de Janeiro au Brésil (novembre)
Les deux réunions lanceront les ajouts de fonctionnalités au working draft de C++29
D’ici la prochaine réunion, de nombreuses téléconférences de sous-groupes sont déjà planifiées

7 commentaires

roxie 2026-04-02

zzz

GN⁺ 2026-03-31

Réactions sur Hacker News

Je trouve regrettable que la fonctionnalité Contracts ait été adoptée dans la norme C++
Cela donne l’impression d’ajouter encore de la complexité à un langage qui a déjà atteint sa limite en la matière
Même Bjarne Stroustrup l’a décrite comme un « design incomplet et gonflé par le travail de comité »
Je pense aussi que cette fonctionnalité comporte trop de pièges potentiels pour être vraiment justifiée
- J’avais moi-même implémenté une extension Contracts pour C++ au début des années 1990
  Mais cela n’avait intéressé personne
  La documentation correspondante est ici
- Beaucoup de gens disent que « C++ est trop complexe », mais il est intéressant de voir que chacun pense à des fonctionnalités complexes différentes
- Le design des Contracts en C++ est peut-être mauvais, mais je pense que le concept lui-même est indispensable à l’évolution du langage
  Comme en Ada ou en Rust, c’est un élément clé pour l’intégration avec la vérification formelle (proof assistant), permettant une vérification statique à la place des tests
  Ada Spark est une bonne référence sur ce point
- La documentation sur les Contracts est vraiment confuse
  Le premier exemple de la documentation cppreference montre au contraire un cas exceptionnel qui modifie l’état
  La syntaxe n’est pas intuitive non plus
  Par exemple, une forme comme asserts_pre(num >= 0) aurait été bien plus claire que pre(num >= 0)
  Mais la concision semble avoir été prioritaire
- Les Contracts ne font que standardiser des pratiques que les développeurs C++ appliquaient déjà de manière informelle
  Plutôt que d’ajouter de la complexité, cela unifie ce que chacun implémentait de son côté et améliore l’interopérabilité
  À mes yeux, une fonctionnalité comme Reflection ajoute davantage de complexité
En tant que développeur C# et Java, je me pose une question
J’aimerais savoir quels types d’applications on développe aujourd’hui en C++
On entend rarement parler des problèmes concrets qu’il résout réellement
La redéfinition de “erroneous behavior” pour les variables non initialisées est intéressante
D’après le document de la norme, cela introduit un coût à l’exécution,
et l’attribut [[indeterminate]] permet de revenir à un undefined behavior
```
int x [[indeterminate]];
std::cin >> x;
```
- Le langage D initialise automatiquement toutes les variables
  Si on veut réellement ne pas initialiser une variable, il faut l’écrire explicitement comme int x = void;
  Il est donc très rare de le faire par erreur
- En parcourant rapidement le document, deux choses m’ont surpris
  1. il n’est pas clair ce que signifie exactement une « valeur déterminée indépendamment » — est-ce un remplissage à zéro, ou une valeur arbitraire provenant de la mémoire ?
  2. je me demande pourquoi [[indeterminate]] fait revenir à de l’UB (Undefined Behavior)
- Cette fonctionnalité pourra probablement être contrôlée via un flag de compilateur
  Certains projets continueront sans doute à préférer l’initialisation manuelle
- Quand je pense aux personnes qui verront [[indeterminate]] plus tard dans le code, c’est effrayant
  Elles finiront soit par perdre du temps à chercher ce que cela signifie, soit par l’ignorer complètement
  Cela me rappelle mon expérience avec Rust, où trop de génériques et de traits rendaient le code difficile à lire
J’ai travaillé dans l’équipe C++ de Microsoft dans les années 1990
À l’époque, je pensais que RTTI représentait la limite de ce que C++ pouvait avoir comme système de réflexion
Voir l’évolution actuelle est impressionnant
Organiser une réunion à Croydon et empêcher tout le monde de partir avant la signature, c’était une stratégie plutôt maligne
Je n’aimerais pas retravailler là-bas
Je me demandais où en étaient GCC et Clang dans leur implémentation de C++26
GCC a déjà fusionné reflection et contracts dans la trunk, mais j’aimerais savoir jusqu’où Clang est allé
- La page d’état de Clang affiche « no » pour les deux,
  tandis que la page de GCC affiche « yes »
- Bloomberg a publié une implémentation de reflection pour Clang ici
  Elle est déjà utilisable dans Compiler Explorer et sert à ajouter la reflection à simdjson
Je me demande si les changements du système de modules de cette norme suffiront à favoriser une adoption plus large en pratique
- Je pense que le WG de C++ devrait, au moins une fois, se concentrer sur les modules et le packaging plutôt que sur de nouvelles fonctionnalités
  C’est précisément là que Cargo de Rust surpasse C++
  Le fait de ne pas pouvoir ajouter une dépendance avec une simple commande cargo add éloigne la nouvelle génération
- La plupart des compilateurs ne prennent toujours pas en charge les header units
  Si CMake adoptait le modèle de compilation en deux étapes de Clang, les performances de build s’amélioreraient fortement,
  et ce n’est qu’alors que les modules seraient véritablement adoptés
- Je pense que les modules sont déjà une idée ratée
  Ils ont très peu de chances de devenir majoritaires
- Honnêtement, j’aimerais qu’on arrête maintenant le développement de C++
  Il y a trop de nouvelles fonctionnalités pour réussir à suivre
  Le système de build est chaotique, et les fichiers d’en-tête devraient désormais disparaître
Hors sujet, mais l’expression « London Croydon » sonne bizarrement
On ne dirait pas plutôt « Croydon, London » ?
- Il existe aussi des expressions inversées courantes comme « London Gatwick Airport »
  Quand on prépare un voyage, il est plus naturel de lire du plus grand territoire vers le plus petit
- Certains parlent en partant du plus spécifique, d’autres du plus général
  S’ils ont écrit « London, Croydon », c’est probablement pour donner l’impression que la réunion s’est tenue à Londres
  « Croydon, London » donne plutôt le sentiment que c’était à Croydon, en périphérie de Londres, donc moins prestigieux — interprétation semi-humoristique
On voit aussi des réactions cyniques du type « cela arrive juste avant la mise à la retraite du langage »
Si C++29 se concentrait uniquement sur des améliorations de qualité et le peaufinage des fonctionnalités existantes, je pense que la communauté ne s’en plaindrait pas vraiment
- Personnellement, je serais déjà satisfait si C++29 ajoutait simplement une fonction random() sur une ligne
- Bien sûr, la réaction de la communauté dépendra aussi des fonctionnalités qui seront ajoutées

coldmonster91 2026-04-02

Après la sortie d’une norme C++, il faut souvent attendre plus de 5 ans avant qu’elle commence doucement à être adoptée dans l’industrie... C’est séduisant, mais ça reste un peu comme un château en Espagne, snif snif

woonsa 2026-04-01

Au lieu d’ajouter des fonctionnalités pour la sûreté mémoire, il suffirait déjà d’interdire les pointeurs pendants ou les références mutables pour améliorer la sûreté mémoire, mais là ils ne font qu’augmenter la complexité du code en ajoutant encore des fonctionnalités.

tsboard 2026-04-01

J’ai eu du mal à passer à Rust, donc c’est encourageant de voir qu’une bonne partie des fonctionnalités que j’attendais a été intégrée au projet de standard C++26. Mais je ne reviendrai quand même pas à C++... haha

heal9179 2026-04-01

Du côté du packaging, il y a aussi des avancées qui viennent de CMake.. https://www.kitware.com/common-package-specification-is-out-the-gate/