Les travaux sur la norme C++ 23 sont terminés et cette nouvelle version porte le nom de code "Pandemic Edition

Version imprimable

15/02/2023, 13h49
Bill Fassinou

Les travaux sur la norme C++ 23 sont terminés et cette nouvelle version porte le nom de code "Pandemic Edition
Les travaux sur la norme C++ 23 sont terminés et cette nouvelle version porte le nom de code "Pandemic Edition"
C++ 23 cherche à améliorer la vitesse de compilation et l'hygiène du code

Herb Sutter, secrétaire du comité de standardisation du langage C++ de l'ISO, a annoncé lundi que les travaux sur la nouvelle norme C++ 23 ont été finalisés lors de la dernière du comité à Issaquah, dans l'État de Washington, aux États-Unis. Place désormais à la production du document final qui sera envoyé au vote d'approbation international (Draft International Standard, ou DIS) et au travail éditorial final, pour être publié plus tard en 2023. Cette version introduit de nombreuses nouvelles fonctionnalités, mais certaines d'entre elles sont des choses que vous n'utiliserez pas si souvent. Il y a également eu plusieurs corrections de bogues.

Dans un billet de billet publié sur son site personnel lundi, Sutter a déclaré que le thème principal de C++23 était "Compléter C++ 20", et certains des points forts incluent le module "std", "if consteval", les paramètres "this" explicites, la simplification du déplacement implicite, des améliorations pour le support d'Unicode, etc., et la fixation de la durée de vie des temporaires dans les boucles "range-for". Sutter a annoncé qu'en plus du travail sur C++23, le comité a également eu le temps de progresser sur un certain nombre de propositions post-C++ 23, y compris la poursuite du travail sur les contrats, l'exécution SIMD, et plus encore.

D'après Sutter, la première réunion en personne annulée par la pandémie aurait été la première réunion du cycle triennal de C++23. Cela signifie que la quasi-totalité du cycle de publication de C++23 et l'ensemble de la phase de "développement" du cycle ont été réalisés via Zoom avec plusieurs centaines de téléconsultations de 2020 à 2022. D'où le nom de code "Pandemic Edition". Plusieurs compilateurs prennent déjà en charge certaines nouvelles fonctionnalités introduites par C++ 23. La nouvelle version du langage de programmation créé par Bjarne Stroustrup prend en charge un module de bibliothèque standard qui accélère la compilation.

https://youtu.be/b0NkuoUkv0M

« Les modules permettent non seulement d'améliorer la vitesse de compilation et l'hygiène du code, mais également d'unifier l'organisation du code source des fonctions ordinaires et des templates. À terme, les modules constitueront l'amélioration la plus significative jamais apportée à la manière dont nous organisons notre code », a déclaré Stroustrup. La distinction .h/.cpp disparaît et le code source C++ est fondamentalement simplifié. Avec le module de bibliothèque standard, "Hello World" devient le suivant :
Code:

1 2 3 4 5 import std; int main() { Std::cout<< "Hello, World!\n"; }
Stroustrup estime que ce code devrait compiler 10 fois plus vite que l'ancienne version utilisant #include <iostream>. Il estime que C++ 23 comporte de nombreuses améliorations mineures, mais certaines ne sembleront pas mineures. Stroustrup a fait remarquer qu'il ne s'agissait pas d'une mise à niveau majeure de C++ comme l'ont été C++ 11 et C++ 20. Comme l'a répété Sutter dans son billet de blogue lundi, il s'agissait plutôt de compléter C++ 20 et, avec un peu de chance, d'apporter quelques fonctionnalités importantes. Toutefois, la pandémie a imposé une limite aux ambitions, notamment la difficulté de se rencontrer en personne.

En conséquence, des fonctionnalités telles que le filtrage, les contrats et un modèle général pour la concurrence (exécuteurs) devront attendre C++ 26. En outre, C++ 23 ne comportera pas une fonctionnalité essentielle qui facilite l'écriture de code destiné à être exécuté dans des environnements informatiques parallèles. La nouvelle norme ne sera pas livrée avec une fonctionnalité d'algorithme asynchrone appelée "expéditeurs et récepteurs" (senders and receivers), qui permettra l'exécution simultanée du code sur un système comportant plusieurs puces, telles que des CPU et des GPU. Il s'agit d'une fonctionnalité attendue de longue date.

Par ailleurs, C++ 23 intervient à un moment où le débat sur la mise au rebut du C/C++ au profit de langages modernes et sûrs pour la mémoire, tels que Rust. Rust a gagné en popularité ses dernières années en raison de sa gestion sécurisée de la mémoire, et une partie de l'industrie conseille - y compris les grandes entreprises telles que Microsoft, Meta et Amazon - désormais de démarrer les nouveaux projets en Rust et non en C++. Selon les commentaires sur l'annonce de la fin des travaux sur la norme C++ 23, le comité doit proposer nouvelles fonctionnalités attrayantes à l'avenir afin de conserver la place de choix du C++ dans l'industrie.

Cette place de choix est actuellement sérieusement menacée par le C++ et même les organisations indépendantes et étatiques participent au débat. Le mois dernier, Consumer Reports, une organisation à but non lucratif spécialisée dans les tests de produit, a plaidé pour que les entreprises abandonnent des langages tels que C et C++ au profit de langages sûrs pour la mémoire tels que Rust. Consumer Reports estime que la sécurité de la mémoire a toujours été une source persistante de défauts dans l'industrie du logiciel, mais que de nouveaux langages permettent désormais de se mettre à l'abri de ces bogues dès la phase de conception.

Selon Consumer Reports, environ 60 à 70 % des vulnérabilités des navigateurs et des noyaux, ainsi que des bogues de sécurité trouvés dans les bases de code C/C++ , sont dus à un manque de sécurité de la mémoire, dont beaucoup peuvent être résolus par l'utilisation de langages à sécurité mémoire. En outre, en novembre 2022, la National Security Agency (NSA) des États-Unis a recommandé aux développeurs de s'éloigner stratégiquement des langages C et C++. Face aux rapports critiquant les problèmes du C++, Stroustrup a déclaré que "la sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++".

« Il n'y a pas qu'une seule définition de la notion de sécurité et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », a déclaré Stroustrup. Il suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc. Bien que beaucoup pensent que Rust acte la mise au rebut du C/C++, il est clair que ces derniers seront encore là pour longtemps.

Sources : Herb Sutter, La norme C++ 23

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous de l'introduction des modules dans la bibliothèque standard du C++ ?
:fleche: Selon vous, en quoi les modules pourraient-ils améliorer l'expérience des programmeurs C++ ?
:fleche: Quel est votre avis sur le débat qui a lieu au sujet du C/C++ et de Rust ?

Voir aussi

:fleche: Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs sur les besoins en termes d'évolution du langage et les comparaisons avec des projets similaires

:fleche: Consumer Reports publie un rapport détaillé encourageant l'adoption généralisée de langages sûrs pour la mémoire tels que Rust, et sensibilise sur les risques liés à la sécurité de la mémoire

:fleche: La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

:fleche: « La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ », d'après Bjarne Stroustrup, contre une sortie de la NSA qui exclut le C++ des langages sécurisés
15/02/2023, 20h07
Padget

Moi ce que j'attends avec impatience c'est la lib network promise depuis bien longtemps dans le standard... et un meilleur traçage du cycle de vie des variables (avec erreurs de compilation à la clé) afin de parvenir à un niveau de sécurité tel que rust
15/02/2023, 20h25
thamn

Je suis surement pessimiste, mais j'ai pas hâte de me prendre la tête avec les modules.
Je sens venir les galères infernales et sans fin pour les projets multiplateforme utilisant différent compilateurs (non non je ne pointe pas du doigt le genial MSVC).
Bon ceci dit, d'ici la que les compilateurs implementent les modules j'ai le temps..
Ca va etre bien :ptdr:
15/02/2023, 20h29
thamn

Citation:

Envoyé par Padget

Moi ce que j'attends avec impatience c'est la lib network promise depuis bien longtemps dans le standard... et un meilleur traçage du cycle de vie des variables (avec erreurs de compilation à la clé) afin de parvenir à un niveau de sécurité tel que rust

Avant d'esperer quelque chose de Rust je conseillerai de l'utiliser pour se rendre compte que pour atteindre son "niveau de sécurité" c'est vraiment pas gagné, et meme selon moi impossible. On ne transforme pas une paillote en bord de plage en un abri anti nucléaire comme ça..
16/02/2023, 09h34
pboulanger
Citation:

et un meilleur traçage du cycle de vie des variables (avec erreurs de compilation à la clé) afin de parvenir à un niveau de sécurité tel que rust

On m'a appris que si tu donnes du poisson à un homme il aura à manger un repas mais que si tu lui apprends à pêcher il n'aura plus jamais faim. Bien qu'un peu caricatural, cette expression est intéressante: vaut-il mieux avoir des développeurs avec pleins d'outils mais qui ne comprennes plus ce qu'ils font ou la complexité cachée derrière une fonctionnalité? ou vaut il mieux former les développeurs à ne plus faire les erreurs?
C'est un problème de philosophie, certes, mais j'y suis confronté régulièrement avec les développeurs juniors:
Code:

1 2 3 4 5 6 l1 = list(range(100000)) l2 = [] for i in l1: if i %2 == 0 and i not in l2: l2.append( i )
ceux-ci ne comprennent même plus que ce bout de code est en o(n²)... Trop faciliter la vie du développeur a 2 impacts:
- cela finit par créer de mauvais développeur
- cela ralentit le code ou la compilation car la sécurité n'est pas gratuite
16/02/2023, 19h38
Padget

je suis d'accord que pour faire de bon dev il faut qu'ils sachent utiliser que les outils de base. jamais je n'irais vers le rust, car je n'aime pas sa syntaxe et sa philosophie du tout assisté. Je me référe toujours au c++ pour tous les autres langage. mais j'aime bien quand le compilo me fourni une analyse statique de mon code pour me reporter les erreurs éventuelles. c'est en ce sens que j' exprimais mon souhait d'une meilleure analyse du cycle de vie, je ne pensais pas qu'on rajoute cette fonctionnalité dans le langege même. j'aime la liberté qu'offre le cpp justement.
16/02/2023, 19h48
Pyramidev
Citation:

Envoyé par pboulanger

On m'a appris que si tu donnes du poisson à un homme il aura à manger un repas mais que si tu lui apprends à pêcher il n'aura plus jamais faim. Bien qu'un peu caricatural, cette expression est intéressante: vaut-il mieux avoir des développeurs avec pleins d'outils mais qui ne comprennes plus ce qu'ils font ou la complexité cachée derrière une fonctionnalité? ou vaut il mieux former les développeurs à ne plus faire les erreurs?

En Rust, la gestion des durées de vie n'est pas cachée, bien au contraire. Il faut parfois même manipuler des annotations de types pour exprimer quelle référence vit plus longtemps que quelle autre (pas souvent, heureusement, mais ça arrive). Sur la gestion de la mémoire, Rust oblige un peu plus que C++ à comprendre ce que l'on fait. Rust ne possède pas de ramasse-miettes.
Citation:
Envoyé par pboulanger

C'est un problème de philosophie, certes, mais j'y suis confronté régulièrement avec les développeurs juniors:

Code:

1 2 3 4 5 6 l1 = list(range(100000)) l2 = [] for i in l1: if i %2 == 0 and i not in l2: l2.append( i )

ceux-ci ne comprennent même plus que ce bout de code est en o(n²)... Trop faciliter la vie du développeur a 2 impacts:
- cela finit par créer de mauvais développeur
- cela ralentit le code ou la compilation car la sécurité n'est pas gratuite
Personnellement, en Python, je préfère que l'opérateur in soit présent plutôt que d'obliger à recoder la recherche à la main. Cela facilite la relecture du code. Effectivement, cela entraîne le risque que des étudiants ne réfléchissent pas à comment c'est implémenté sous le capot. Mais de plus en plus de recruteurs français font appel à des tests CodinGame ou Codility dont certains exercices demandent de faire attention à la complexité algorithmique, donc ce dernier point sera rattrapé et du code à la fois performant (pour du Python) et concis pourra être écrit :

Code:

even_numbers = {x for x in l1 if x % 2 == 0}

Mais ton message répond à Padget qui parlait de Rust, pas de Python. Or, en Rust, je pense qu'il y a moins de coûts cachés qu'en C++. En tout cas, c'est vrai pour les allocations dynamiques.
En effet, en C++, il y a plein de situations où le constructeur de copie est appelé implicitement, même quand celui-ci fait une allocation dynamique. En Rust, par contre, il faut appeler explicitement la méthode clone du trait Clone.
16/02/2023, 19h57
mintho carmo

Citation:

Envoyé par pboulanger

vaut il mieux former les développeurs à ne plus faire les erreurs?

C'est juste illusoire et naif. Tout le monde connait les problèmes posés par les pointeurs en C ou C++ depuis 30 ans, ca n'empêche pas d'avoir des bugs depuis 30 ans. Quelque soit la compétence des devs, il y aura toujours des erreurs. On peut diminuer le taux d'erreurs par lignes de code, par exemple en consacrant plus de temps (ce qui coute de l'argent et n'est fait que dans les projets critiques), mais une meilleure méthode reste d'avoir un langage qui est plus résistant aux erreurs. C'est le but de Rust, des derniers ajouts dans le C++ (et du groupe de travail SG23 du comité C++) et pleins de langages.

Et l'apprentissage bottom-up (commencer par les détails et aller vers le général) ne permet pas forcément d'avoir de meilleurs développeurs. De mon expérience, j'aurais même tendance à dire que c'est l'inverse. Les vieux devs, qui ont appris les détails internes en premier, sont souvent plus mauvais pour faire du code de qualité (safe, maintenable, sur des gros projets)
16/02/2023, 22h16
pboulanger

Citation:

Mais ton message répond à Padget qui parlait de Rust, pas de Python. Or, en Rust, je pense qu'il y a moins de coûts cachés qu'en C++. En tout cas, c'est vrai pour les allocations dynamiques.
En effet, en C++, il y a plein de situations où le constructeur de copie est appelé implicitement, même quand celui-ci fait une allocation dynamique. En Rust, par contre, il faut appeler explicitement la méthode clone du trait Clone.

En fait les coûts cachés sont partout. En C++, je pourrais te citer la différence entre std::map et std::unordered_map...
Quand tu écris une fonction avec une interface dans le style:

Code:

MyClass my_operation(MyClass s1, MyClass s2)

les passages par valeurs puis le retour par valeur génèrent un gros coût caché... Tout comme les "+" en série pour construire une chaîne de caractères.

Chaque langage a ses qualités et ses défauts et des pièges à éviter... A trop faciliter on oblitère toute forme de réflexion. L'école française en est un bon exemple: https://www.youtube.com/watch?v=-S-obOJLNeU"]https://www.youtube.com/watch?v=-S-obOJLNeU
16/02/2023, 22h54
Pyramidev

D'ailleurs, je viens de me rappeler d'un cas où C++ est par défaut plus performant que Rust si on ne fait pas attention. Je vais le citer pour compléter mon message précédent pour éviter qu'il soit trop biaisé pro-Rust au niveau des coûts explicites.

En C++, std::sort fait un tri instable. Pour faire un tri stable, mais moins performant, il faut appeler std::stable_sort.
En Rust, sort est par défaut un tri stable pour éviter de surprendre l'utilisateur. Pour faire un tri plus performant, il faut choisir explicitement sort_unstable.
Dans cet exemple, les deux conceptions peuvent se défendre.

Citation:

Envoyé par pboulanger

L'école française en est un bon exemple:

Je l'ajoute à ma todo-list des longues vidéos à voir, car le thème m'intéresse. Mais j'ai quelques longues vidéos de retard. Je ne sais pas encore quel jour j'aurai le temps de la voir.
17/02/2023, 16h52
Fagus
Citation:
Envoyé par pboulanger

...vaut-il mieux avoir des développeurs avec pleins d'outils mais qui ne comprennes plus ce qu'ils font ou la complexité cachée derrière une fonctionnalité? ou vaut il mieux former les développeurs à ne plus faire les erreurs?
C'est un problème de philosophie, certes, mais j'y suis confronté régulièrement avec les développeurs juniors:

Code:

1 2 3 4 5 6 l1 = list(range(100000)) l2 = [] for i in l1: if i %2 == 0 and i not in l2: l2.append( i )

ceux-ci ne comprennent même plus que ce bout de code est en o(n²)... Trop faciliter la vie du développeur a 2 impacts:
- cela finit par créer de mauvais développeur
- cela ralentit le code ou la compilation car la sécurité n'est pas gratuite
Ouch, ce code pique les yeux :?

À mon humble avis, c'est en effet un problème de code caché.
Quand on écrit le bon code avec une compréhension de liste, a=[x for x in range (0,100000,2)] ou encore plus simple sans... a=list(range(0, 100000, 2)) , plein d'optimisations cachées intelligentes font que le bon code s'exécutera plus vite et avec moins de mémoire. Mais ça implique de comprendre au moins à peu près ce que fait la machine en terme d'allocation et les concepts spécifiques au langage (générateur, itérateur, la vitesse relative du python et de ses fonctions en c...).

Est-ce qu'il faut passer par le c ? En c, les instructions ne sont pas cachées et on voit ce que fait la machine... En C++ ou dans n'importe quel langage objet, quand on exécute des fonctions encapsulée, la seule façon de savoir si c'est optimisé c'est d'avoir une idée de la manière dont elle fonctionne ou de mesurer.

Donc, à mon humble avis, pas besoin de bien connaître les langages historiques pour écrire en haut niveau, c'est juste qu'il faut connaître un peu le fonctionnement caché du langage de haut niveau et mesurer les performances parfois.

Former à ne pas faire d'erreurs... ce serait bien, dans un monde parfait ;)
17/02/2023, 18h11
mintho carmo

Citation:

Envoyé par Fagus

Donc, à mon humble avis, pas besoin de bien connaître les langages historiques pour écrire en haut niveau, c'est juste qu'il faut connaître un peu le fonctionnement caché du langage de haut niveau et mesurer les performances parfois.

Je suis d'accord avec toi sur ce point. En particulier parce que je pense que ta phrase juste avant est discutable :

Citation:

Envoyé par Fagus

Est-ce qu'il faut passer par le c ? En c, les instructions ne sont pas cachées et on voit ce que fait la machine... En C++ ou dans n'importe quel langage objet, quand on exécute des fonctions encapsulée, la seule façon de savoir si c'est optimisé c'est d'avoir une idée de la manière dont elle fonctionne ou de mesurer.

C'etait vrai il y a 30 ans (ou dans le C embarque) que le code C etait proche de l'assembleur genere, mais sur un ordinateur moderne, avec un systeme d'exploitation moderne, c'est loin d'etre vrai. Une simple allocation memoire passe par pleins d'etapes en interne dans le systeme, pour gerer la memoire virtuelle, la memoire protegee, etc. Un simple calcul peut faire intervenir les differentes memoires caches, le parallelisme, etc.

Sans prendre en compte ces problematiques, on ne peut pas comprendre par exemple pourquoi certains algos sont plus efficace en pratique malgre qu'ils ont une moins bonne complexite algo, ou pourquoi certaines structures de donnees comme les listes sont souvent peu performantes par rapport a des tableaux avec des donnees contigues en memoire.

On voit meme perfois l'effet pervers inverse : des gens qui vont se concentrer uniquement sur la complexite algos, sans faire de mesures reelles. Ou vont preferer reecrire les algos parce que persuade qu'ils font mieux que les implementations standards.

A partir du moment ou l'on fait le constat que le C ne permet pas de comprendre ces notions internes et que pour les apprendre, il faut les apprendre explicitement, alors on ne peut que conclure que le langage utilise pour l'apprentissage n'a pas d'importance. Ce qui compte, c'est la qualite du contenu et de la pedagogie. Un personne, qui apprend le Python/Java/peu importe et a qui on explique l'impact des differentes syntaxes, sera plus competent que celui qui fera du C et a qui on n'explique pas tout cela.

L'argument "il faut commencer par du C pour comprendre ce qu'il se passe en interne" est juste une illusion (et plus generalement l'approche bottom-up -- sauf cas particulier).
17/02/2023, 20h37
Invité

Pourquoi comparer C++ à Rust ? Au-delà des problèmes de sécurité, ces deux langages ne partagent pas du tout la même philosophie et il est peu probable que leurs développeurs passent de l'un à l'autre.
17/02/2023, 21h01
mintho carmo

Citation:

Envoyé par Jeff_67

Pourquoi comparer C++ à Rust ?

Au moins 3 raisons :

- les devs s'inspirent de ce qui est fait dans d'autres langages, pour creer des nouveaux idioms ou faire evoluer leur langage. Beaucoup de choses dans le C++ vient des autres langages objets, des langages fonctionnels, etc. Et en particulier Rust, qui est un tres bon terrain d'entrainement pour des nouvelles idees (comme il n'a pas l'historique du C++). Il y a par exemple de proposals pour ajouter la notation des lifetimes en C++ comme il existe dans Rust.

- parce qu'une partie du code C++ peut etre reecrit en Rust, pour faire des applications hybrides. C'est de plus en plus courant pour les grosses applications modernes d'utiliser plusieurs langages et Rust s'integre pas trop mal avec le C et le C++.

- parce qu'apprendre d'autres langages, d'autres paradigmes permet de prendre du recul avec son propre langage de predilection, etre plus critique avec ce qu'on fait. C'est assez courant que les "theoriciens" du C++ pratiques d'autres langages ou creent des nouveaux langages, pour ameliorer leur comprehension des problematiques posees et trouver de nouvelles solutions originales.
17/02/2023, 21h34
Pyramidev

Citation:

Envoyé par Jeff_67

Pourquoi comparer C++ à Rust ? Au-delà des problèmes de sécurité, ces deux langages ne partagent pas du tout la même philosophie et il est peu probable que leurs développeurs passent de l'un à l'autre.

De mon côté, à une époque, le C++ était mon langage préféré. À présent, je préfère Rust.

Rust s'inspire beaucoup du C++. Par exemple, il a repris le RAII et le zero-overhead principle et pousse même encore plus loin ces logiques. Rust fait aussi très attention à la rétrocompatibilité depuis la version 1.0.

Par contre, la gestion du polymorphisme est différente. En C++, la POO et la programmation par templates ont pas mal de différences entre elles. Rust gère les abstractions de manière encore différente. Mais serait-ce cela qui bloque certains développeurs C++ ?
18/02/2023, 00h11
mintho carmo

Citation:

Envoyé par Pyramidev

Mais serait-ce cela qui bloque certains développeurs C++ ?

Pour moi, il y a plusieurs raisons qui font qui les devs (C++) ne passent pas tous massivement a Rust (et ne le feront probablement pas).

Pour commencer, tu as dis toi même, il y a des différences entre le C++ et Rust. Ca veut dire réapprendre tout. Et ca veut dire aussi tout réécrire.

Et c'est déjà un gros questionnement que j'ai sur Rust. Quand on voit les rapports de bugs critiques, c'est souvent des bugs bien connus (memory leaks, buffer overflow, conversions, etc), qui sont globalement bien gérés par les compilateurs et les analyzers statiques. Ca veut dire que ces bugs critiques viennent surtout de code legacy ou de devs qui continue a faire du C++ old school. Mais si on fait du C++ "moderne", est-ce qu'on n'aura pas un taux d'erreur par ligne de code proche de Rust ? Est-ce que le bénéfice de Rust, en termes de sécurité, ne viendrait pas au final principalement du simple fait que les gens se forment et supprime le vieux code legacy ?

Je lisais par exemple récemment le cours de Guillaume Gomez sur Rust, dans lequel il présente 2 exemples de sécurité que permet Rust (de mémoire) : retourner une référence sur une variable locale et une boucle qui sort des bornes d'un tableau. Le premier est très bien détecté par les compilateurs (et il y a des travaux pour améliorer ça) et le second est bien géré par les range for loop ou les range views, en C++.

J'ai regardé récemment l'implementation de certains programme de coreutilities en Rust. C'est du code finalement assez simple (ce qui n'est pas surprenant, vu qu'il est écrit en C, il n'utilise pas des concepts comme le polymorphisme d'heritage ou les templates), et, pour cet exemple particulier, je pense qu'on obtiendra le même niveau de sécurité de la mémoire en C++ qu'en Rust, sans surcoût.

Un autre problème est que Rust porte pas mal a confusion quand on vient du C++. Certaines termes (par exemple les macros) n'ont rien a voir entre les langages (dans Rust, c'est plus de la classe generation et de l'introspection/reflexion). Ce qui complique encore plus l'apprentissage.

Un autre problème est que Rust a justement voulu fait les choses différemment. Cela implique que toutes les connaissances, pratiques, idiomes, etc. qu'on a conçu pendant 20 ans de POO vont à la poubelle. Je regardais récemment le design des libs de GUI en Rust et les devs bloquent sur les problèmes de design. Des choses qui se font simplement en C++, comme les grosses hiérarchies d'objets dans une GUI, est beaucoup plus complexe a gérer en Rust. Et l'approche avec des traits comme en Rust (que le C++ peut faire aussi) est très bien quand les types peuvent être résolus à la compilation, mais dans pleins de cas concrets, c'est pas possible. Et c'est pour ça que beaucoup de libs GUI en Rust sont juste des bindings.

Et c'est un sentiment général que j'ai sur Rust. Il a un meilleur design pour faire certaines choses, mais pas pour tout faire mieux. La question est alors de savoir s'il veut mieux utiliser Rust et galérer pour certains types de projets (ou ne pas utiliser Rust pour ces projets) ou utiliser un langage plus polyvalent comme C++, auquel on ajoutera progressivement ce qui est intéressant dans Rust ? Personnellement, j'ai l'impression que l'évolution du C++ va dans la bonne direction et assez rapidement, ce qui permet au C++ d'être plus intéressant a court terme (pas besoin de tout réécrire) et a long terme (évolution progressive vers les nouvelles pratiques).

L'exemple des GUI me permet de parler aussi d'un autre problème (celui dont parle Stroustrup) : la sécurisation de la mémoire n'est pas la seule source de bugs. La plus grosse source d'erreur est probablement un manque d'inattention (que celui qui n'a pas lu 1000 fois un code sans voir une erreur évidente me jette le premier clavier). La syntaxe parfois complexe de Rust ne va pas aider sur ce point. Et même pour la mémoire. Si Rust sécurise parfaitement la mémoire dans le code safe, mais qu'on doit mettre des `unsafe` toutes les 100 lignes, ou utiliser des bindings qui ne sont pas safe en interne, alors utiliser Rust ne va pas forcément permettre d'obtenir une meilleure qualité logicielle. En tout cas, pas forcément plus que ce qu'on pourrait avoir avec le développement des outils et pratiques.

Un autre problème avec Rust, c'est que cela reste un langage assez jeune, donc avec un manque important de libs, d'outils, de devs compétents a embaucher qui auraient travaillé sur des gros projets en Rust. L'écosystème est a considérer aussi quand on parle de dev pro.

Une opinion très personnelle, c'est que Rust n'a pas de feature killer qui pourrait justifier à elle seule de passer à Rust. Il a des fonctionnalités que le C++ n'a pas, ce point est sur. Mais est-ce des choses qui sont d'un usage assez courant pour que cela a un impact sur la grosse majorité du code ? En C++, on a beaucoup de fonctionnalités avancées, par exemple une grosse partie de ce qui concerne les templates, la programmation générique et le compile time, sont pas destinés (a mon sens) à être utilisé dans les codes finaux, mais dans les bibliothèques standard. Pour Rust, j'ai le même sentiment : beaucoup de choses qui sont mises en avant pour justifier Rust sont en fait d'un usage peu important et donc ne justifie pas de passer a Rust (tout au moins, un bénéfice pas assez important pour compenser le problème de tout réécrire).

La question est donc, pour un dev C++, de savoir s'il veut mieux passer a Rust, avec toutes les contraintes que cela pose, ou suivre simplement l'évolution du C++, apprendre les nouvelles techniques, utiliser les nouveaux outils, etc. Mon avis (et le choix que j'ai fait) est de miser sur l'évolution du C++. A la rigueur, envisager Rust que pour certains types de projets from scratch.