IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

C++26 est prêt : la nouvelle norme apporte des améliorations en matière de sécurité mémoire et serait la version « la plus aboutie » depuis C++11.
Elle introduit les contrats et la bibliothèque std::execution

Le , par Mathis Lucas

1.4KPARTAGES

17  0 
Le comité ISO C++ a achevé les travaux techniques sur C++26 à Londres Croydon, au Royaume-Uni. Les derniers commentaires internationaux sur le brouillon ont été résolus, et le document final sera soumis au vote international (DIS) avant publication officielle par l'ISO. Cette version majeure ajoute de nombreuses nouvelles fonctionnalités au langage et apporte des améliorations en matière de sécurité mémoire. Elle a toutefois suscité quelques réserves de la part des critiques qui voulaient doter C++ d'un modèle de sécurité inspiré de Rust. Pour le secrétaire du comité Herb Sutter, cependant, C++26 est la version la plus aboutie depuis C++11.

C++26 est le nom informel donné à la version de la norme 14882 de l'Organisation internationale de normalisation (ISO) et de la Commission électrotechnique internationale (CEI) relative au langage de programmation C++ qui succède à la version C++23. C++26 a été officiellement finalisé le 28 mars 2026 par le comité international chargé de la normalisation (WG21) du langage. Le comité a également annoncé avoir adopté le calendrier de C++29.

Herb Sutter : C++26 est la version la plus importante depuis C++11

La réunion à Londres Croydon, au Royaume-Uni, était la dernière consacrée aux travaux techniques sur C++26 ; aucune fonctionnalité n'a été ajoutée ni retirée, l'essentiel du travail portant sur le traitement des 411 commentaires reçus lors du vote international précédent. Selon Herb Sutter, secrétaire du comité de standardisation du langage, « C++26 est la version la plus marquante depuis C++11 ». Elle s'articule autour de quatre grandes nouveautés.

La réflexion (Reflection) : une révolution pour le langage C++

La réflexion est décrite comme la plus grande avancée pour le développement C++ depuis l'invention des templates. Elle permet pour la première fois au langage C++ de s'autodécrire, offrant aux développeurs les clés pour accéder à la machinerie interne du code afin d'analyser et de manipuler les entités du programme directement au moment de la compilation. Cette fonctionnalité vise également à augmenter la productivité des programmeurs C++.


Elle permet de générer du code à la compilation, ouvrant la voie à des abstractions efficaces d'une puissance inédite. Ce moteur de réflexion est perçu comme un outil de puissance inédite, et il est prévu qu'il faille une décennie entière à la communauté pour en explorer tout le potentiel technologique.

« Les premières fonctionnalités de réflexion à la compilation incluses dans le projet C++26 marquent le tournant le plus transformateur de l’histoire de notre langage en nous offrant le nouveau moteur le plus puissant dont le C++ ait jamais disposé pour exprimer des abstractions efficaces, et il nous faudra la prochaine décennie pour découvrir tout ce dont cette fusée est capable », a déclaré Herb Sutter. En bref, cette réflexion C++ moderne permet :

  • l'inspection des types, membres, fonctions et annotations ;
  • la génération de code C++ automatique à la compilation ;
  • un métaprogrammation compile-time (compile-time metaprogramming) expressive, sans macros.


La norme C++26 apporte la sécurité mémoire au langage

C++26 introduit des améliorations importantes en matière de sécurité mémoire, accessibles sans modification du code existant, simplement en recompilant en C++26. L'avancée la plus notable est la suppression complète des comportements indéfinis liés à la lecture de variables locales non initialisées, une source historique majeure de vulnérabilités logicielles. Toute cette catégorie de vulnérabilités disparaît après que vous avez recompilé en C++26.

En complément, cette nouvelle version introduit un durcissement de la bibliothèque standard qui impose des vérifications de limites (bounds safety) pour les conteneurs les plus utilisés comme vector, string, span, etc. Ces mesures, déjà testées à grande échelle par des géants tels que Google et Apple, ont prouvé leur efficacité en réduisant drastiquement les bogues et les plantages en production avec un impact minimal sur les performances du code.

Selon un long compte rendu publié par Herb Sutter le 29 mars, chez Google, ce durcissement de la bibliothèque standard a déjà corrigé plus de 1 000 bogues, devrait en prévenir entre 1 000 et 2 000 par an, et a réduit le taux d'erreurs de segmentation (segfault) de 30 % sur leur flotte de production.

Les contrats : préconditions, postconditions et assertions

Les contrats (Contracts) introduisent dans le langage des mécanismes formels pour définir des préconditions, des postconditions et des assertions directement dans les déclarations de fonctions. Cette fonctionnalité remplace avantageusement la macro assert du langage C en offrant une intégration native qui renforce la sécurité fonctionnelle et la clarté des interfaces logicielles. Cette nouvelle fonctionnalité ne bénéficie pas du soutien de tous.

L'intégration des contrats a fait l'objet de débats techniques prolongés au sein du comité ISO en raison de diverses préoccupations d'experts. Elles sont toutefois minoritaires. Les membres ont finalement voté pour leur maintien dans C++26, estimant que l'apport pour la fiabilité des programmes l'emportait sur les divergences de conception. Lors du vote final pour livrer le standard, le résultat a été de 114 voix pour, 12 contre et 3 abstentions.

« std::execution » : le modèle asynchrone unifié de C++

La bibliothèque std::execution (ou modèle « Sender/Receiver ») fournit un cadre unifié pour gérer l'asynchronisme et le parallélisme. Cependant, elle reste plus difficile à adopter que la plupart des autres, par manque de documentation et de bibliothèques d'accompagnement. « std::execution est ce que j'appelle le « modèle asynchrone du C++ ». Il offre un cadre unifié pour exprimer et contrôler la concurrence et le parallélisme », a écrit Herb Sutter.

Cet ajout présente d’importantes propriétés de sécurité, car il facilite l’écriture de programmes utilisant une concurrence et un parallélisme structurés (avec des durées de vie rigoureusement imbriquées) qui sont, par construction, exempts de conflits d’accès aux données. C’est un avantage considérable.

Autres fonctionnalités intégrées dans la norme ISO C++26

  • instructions d'expansion (P1306) : modèle permettant de parcourir des plages à la compilation, telles que des tuples et des résultats de réflexion ;
  • std::simd (P1928) : types parallèles portables ;
  • std::inplace_vector (P0843) : vecteur redimensionnable dynamiquement avec une capacité fixe et sans allocation sur le tas ;
  • #embed (P1967) : intégration de ressources binaires dans le code source ;
  • exceptions constexpr (P3068) : levée et interception d'exceptions à la compilation ;
  • std::hive (P0447) : un conteneur basé sur des compartiments qui réutilise la mémoire des éléments effacés ;
  • std::linalg (P1673) : une interface d'algèbre linéaire à fonctions libres basée sur BLAS ;
  • pointeurs Hazard et RCU (P2530, P2545) : blocs de construction de structures de données concurrentes ;
  • renforcement de la bibliothèque standard (P3471) : vérification des limites et autres contrôles de sécurité pour les conteneurs standard.


Le comité ISO s'attend à une adoption rapide en industrie

L'adoption de C++26 par l'industrie devrait être particulièrement rapide, car la demande des développeurs est extrêmement forte et les principaux compilateurs comme GCC et Clang intègrent déjà une grande partie des fonctionnalités. GCC a déjà intégré la réflexion et les contrats dans son dépôt principal. « Je m'attends à ce que C++26 soit adopté plus rapidement par le secteur, comparé à C++17, C++20 et C++23 », a déclaré Herb Sutter.

Cap sur C++29 : ajouter encore plus de sécurité mémoire

Le comité a d'ores et déjà adopté le calendrier de C++29 lors de la dernière réunion à Croydon. Herb Sutter a rapporté que ce nouveau cycle de trois ans se concentrera prioritairement sur le renforcement de la sécurité mémoire à travers le concept de profils et la réduction continue des comportements indéfinis. Les profils ont été proposés par le créateur du langage C++, Bjarne Stroustrup. Mais cette fonctionnalité fait l'objet de controverses.

« Le groupe de travail sur la sécurité et la sûreté a voté pour donner la priorité aux Profils plutôt qu'à Safe C++. Demandez aux responsables des Profils de vous tenir au courant. Safe C++ n'est pas poursuivi », a rapporté Sean Baxter, auteur du compilateur Circle C++. Safe C++ visait à doter le langage d'un modèle de sécurité inspiré de Rust, mais il a été rejeté, car il introduirait des contraintes jugées trop lourdes pour l’écosystème C++.

Cette transition vers un C++ plus sûr par défaut tout en respectant le principe de "zéro coût" marque le début d'une nouvelle ère pour le langage. Un rapport d'expérience présenté par Apple décrit comment le moteur de rendu de navigateur WebKit a durci plus de 4 millions de lignes de code en utilisant une approche par sous-ensemble du langage, fermant plusieurs classes de vulnérabilités et empêchant l'exploitabilité de nombreux bogues.

Prochaines étapes

Les deux prochaines réunions du comité se tiendront à Brno (Tchéquie) en juin et à Búzios (Brésil) en novembre, où débutera le travail sur C++29. Herb Sutter a annoncé que lors de ces deux réunions, le comité commencera à travailler sur l'ajout de fonctionnalités au nouveau projet de travail C++29.

Source : billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des nouvelles fonctionnalités intégrées au C++26 ?
Quelles sont les nouvelles fonctionnalités que vous jugez les plus pertinentes ?
Le comité ISO prévoit une courbe d'adoption rapide pour C++26. Qu'en pensez-vous ?
La sécurité mémoire devient une priorité pour le comité de standardisation du langage. Qu'en pensez-vous ?

Voir aussi

Le projet Safe C++, visant à doter le langage d'un modèle de sécurité inspiré de Rust, est mis de côté pour donner la priorité aux « Profils », une alternative controversée proposée par le créateur du langage

Vers un C++ plus sûr ? Avec les extensions Safe C++, la communauté veut répondre aux défis modernes de la sécurité des logiciels, dans un contexte où plusieurs recommandent de le remplacer par des alternatives

Carbon va-t-il remplacer le C++ ? Le projet Carbon explore une direction future possible pour le C++ étant donné les difficultés à l'améliorer et mise sur l'interopérabilité comme base de travail
Vous avez lu gratuitement 1 699 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de freesket
Membre du Club https://www.developpez.com
Le 05/11/2026 à 12:35
Clairement les Contrats sont portés par Bloomberg.

Tels que proposés par le P2900, les Contrats sont dangereux pour la sécurité. Ce que ne précise pas l'article, c'est la manière dont les auteurs de P2900 ont fait pression sur le WG21 pour être validés. Le vote avec les "114 voix pour" n'est pas forcément une validation définitive. Le vote DIS est justement une soupape de sécurité : il permet aux experts des instances nationales (NB), qui ne peuvent pas toujours participer à chaque réunion du WG21, de s'exprimer. Que des membres du WG21 tirent la sonnette d'alarme (via une pétition) pour alerter ces instances nationales est sain, c'est à elles de juger si cette alerte est valable.

Voici pourquoi renvoyer C++26 avec les Contrats inchangés au FDIS est voué à l'échec et pourquoi les auteurs de P4433R0 (qui exigent un passage en force) sont dans une impasse :

- Le couplage avec la STL est artificiel : Retirer les Contrats n'est pas un drame. Même si la spécification actuelle du STL hardening s'appuie dessus, les découpler est tout à fait possible. D'ailleurs, il a déjà été statué (P3878R1) que le durcissement de la STL ne doit jamais utiliser le mode "observe".

- Le danger du mode "observe" : Ce mode signifie que vous pouvez détecter une faille de sécurité critique ou un comportement indéfini (UB), la journaliser, et... continuer l'exécution du programme avec un état corrompu.

- La destruction des garanties noexcept : Pour éviter de casser la compatibilité (ABI), le compilateur continuera de dire qu'une fonction est noexcept(true), mais une exception lancée par un contrat violé pourra désormais la traverser silencieusement.

- La violation de l'ODR (One Definition Rule) : Puisque c'est le système de build (les flags de compilation) qui décide du mode d'exécution des Contrats, une même fonction dans un header peut être compilée avec "enforce" dans un fichier A, et "ignore" dans un fichier B. Le comportement à l'édition de liens devient une loterie (le fameux "mixed-mode").

- Ville Voutilainen (développeur au sein de GCC et qui a participé à l'implémentation de P2900 dans ce dernier, il sait donc de quoi il parle) a proposé des alternatives (comme P4009R0 / P4324R0) qui résolvent ces critiques. Sa solution est bien plus légère et robuste : elle s'appuie sur la bibliothèque standard (std::pre, std::post) plutôt que sur une lourde machinerie du langage.

- Lisez P4381R0 (Chairing SG21 and then objecting to Contracts : John Spicer)

Le but caché de P2900 était de placer les Contrats au centre de la résolution des UB via P3100. Ils voulaient que les Contrats "contrôlent" les Profils de sécurité ! Comment une machinerie optionnelle, qui viole l'ODR, ment sur noexcept et permet d'ignorer les failles de sécurité, peut-elle être la fondation de la sécurité mémoire de C++29 ?

Les deux seules options valides pour que le train de C++26 parte, c'est de retirer cette fonctionnalité ou passer effectivement par une TS.

Sean Baxter a proposé "Safe C++" (en 2024 si mes souvenirs sont bons), un dialecte très proche de Rust dans le compilateur C++... C'est une bonne idée sur le papier pour réveiller le comité, mais pourquoi écrire du Rust avec la syntaxe C++ au lieu de faire du Rust directement ? "Safe C++" risque de créer un schisme digne de "Python 2 vs Python 3", c'est la raison pour laquelle le WG21 l'a écarté (pour le moment).

Heureusement, les Profils de sécurité natifs (std::init et std::invalidation) sont en cours de spécification (vous pouvez tester les prototypes sur Compiler Explorer en cherchant P4324). Le profil d'invalidation se base sur une approche ascendante (bottom-up, cf. P4296R0) avec des annotations non virales. Sean Baxter critique cette approche (et a déjà ouvert des tickets, principalement sur la STL qui n'est pas encore totalement annotée, mais c'est normal...), mais des échanges récents (de Sean Baxter) avec des experts comme Marcos Bracco montrent que ce système semble fonctionner sur du code réel avec très peu de faux positifs (P4415). C'est un premier jet, ne cherchez pas la perfection immédiate, mais cela semble la seule voie viable pour moderniser C++.

Les profils ne cherchent pas forcément à s'appliquer sur du code legacy (comme Safe C++) mais sur du code "modern C++ greenfield". Pour le code "legacy", Clang propose son "Lifetime Safety Analysis".

Pour ceux qui veulent lire les documents ISO évoqués, rendez-vous ici : https://www.open-std.org/jtc1/sc22/w...s/papers/2026/
4  0 
Avatar de Jacti
Membre habitué https://www.developpez.com
Le 11/11/2026 à 17:17
Citation Envoyé par daerlnaxe Voir le message
Est ce que la perte de l'héritage multiple ne va pas poser problème ?
Quel problème ?
Il n'a jamais été produit d'exemple où l'héritage multiple était indispensable. On peut toujours se débrouiller sans lui.
0  0