Discussion :

[foetus]

Et oui, ça s'appelle être un professionnel, savoir utiliser son outil de travail. Incroyable, non ?

Mais tu as plusieurs types d'outils professionnels pour sécuriser son code

• le C++ avec ses pointeurs intelligents, ses vues ... CRT, RAII, ..
• le Rust avec son compilateur, borrow checker, ...
• Java et C# qui utilise 1 machine virtuelle/ ramasse miettes

Et depuis 5-6 ans on reproche au C++ de demander des profils rares (> 8 ans d'expérience, 1 truc comme cela), d'avoir des temps de développement assez longs ... et la liste des bugs mémoire toujours aussi importante.
Les normes depuis C++11 n'ont rien amélioré (que ce soit sur la sécurité du code que sur la gestion des dépendances ou sur la facilité de développer/ debugger).

Je sais que lorsqu'on maîtrise le C++ on se sent "supérieur", meilleur ... le C++ devient 1 b*rdel

Et depuis 5-6 ans pleins de sociétés (même le noyau Linux et FFmpeg) se forment sur Rust et cela semble faire son petit bonhomme de chemin ... le seul truc qui reste au C++ c'est sa vitesse d'exécution et sa énorme base de codes
D'ailleurs ce n'est pas pour rien que depuis 2022-2023, le comité C++ réfléchit à intégrer le borrow checker (il me semble que le comité C++ avait annoncé 1 grande surprise en 2022-2023)

Donc voila il y a 2 types de professionnels : ceux qui font du C++ et les autres

[Bktero]

Comme un électricien doit savoir câbler correctement et respecter les normes

J'ai rénové mon nouvel appartement en 2023. L'immeuble avait 50 ans.

J'ai changé toutes les prises et tous les interrupteurs. Pourquoi ? Pour en avoir des éléments modernes plus sécurisés. Par exemple, les interrupteurs modernes ne permettent pas de prendre une tige de fer, de l'enfoncer dans un des trous, et de mourrir. Il faut prendre 2 tiges et enfoncer dans les 2 trous en même temps pour désenclencher la sécurité. Autre exemple : quand tu "ouvres" une prise ou un interrupteur moderne, il n'y a pas de pièce nue sous tension et donc tu ne peux pas mourrir juste en touchant un truc.

J'ai rajouté aussi la terre sur certaines prises (malheureusement pas sur toutes) car il y a 50 ans, on ne cablait pas la terre.

Les normes et les façons de faire évoluent. Ce qui était OK il y a quelques années peut ne plus l'être aujourd'hui. A un instant T, on fait du mieux qu'on peut. Si à l'instant T+1, on trouve encore mieux, pourquoi ne pas faire encore mieux ?

Et oui, ça s'appelle être un professionnel, savoir utiliser son outil de travail

C'est aussi choisir son outil de travail.

Notre métier développeur.se n'est pas de connaitre par coeur toutes les subtilités du C++. C'est de produire des logiciels de qualité au meilleur coût. Connaitre par coeur les subtilités du C++ est une nécessité quand nous utilisons C++ pour réaliser ces logiciels.

Nos façons de coder en C++ ont évolué avec les années parce que le langage a évolué. Personne aujourd'hui ne défendrait sérieusement l'usage de pointeurs nus sous prétexte que "les vrai.e dev savent gérer la mémoire manuellement". On fait du RAII et on utilise les pointeurs intelligents de la std.

Après de nombreuses années de C++, je fais du Rust depuis quelques mois. Je pense qu'il est encore un peu tôt pour dire que Rust doit remplacer C++. Mais je trouve qu'il est déjà bien assez tard pour ne pas essayer sérieusement ce langage. Ne serait-ce que pour se rendre compte de certains manques du C++ et se demander comment on pourrait l'améliorer.

[jo_link_noir]

Ce qui étonne aussi c'est que les reproches s'adressent au C++ et au C. Par contre Java, Python, Javascript, Pascal , Fortran , Basic ... là la mémoire et le reste c'est nickel

En fait cela part d'un constat assez simple: ~70% des CVE sont liées à des erreurs mémoire (buffer overflow, use after free, etc) et concernent principalement C et C++. Pour ne rien arranger, ce sont aussi les plus critiques. Les autres langages cités n'ont pas ce problème puisqu'ils font systématiquement une vérification des bornes pour lancer une exception et utilisent un GC. En gros, on perd en contrôle ce qu'on gagne en sécurité.

Je conseille la lecture de ce papier: Secure by Design: Google's Perspective on Memory Safety.

Du coup, pourquoi un focus sur Rust ? Parce qu'il se veut sécurisé par design sans compromit sur les performances. Par conséquent, il joue dans la même cour que C ou C++. Quand on reste dans le monde safe de Rust, le langage et la bibliothèque standard ont de forte garanties sur les bugs mémoire. Quand on a besoin de chose spécifique, on peut utiliser des blocs unsafe. En prenant les catégories listées dans le papier:

- Spatial Safety bugs (e.g. “buffer overflow”, “out of bounds access”): via les fonctions qui retournent un Option plutôt qu'une valeur hors borne (le pattern matching et la destructuration aident aussi à ne pas lire la valeur dans l’Option sans vérifier qu'il est valide). Si on ne veut pas de vérification sur les accès (et donc pas d'Option), on passe en unsafe (gros warning) ou on utilise des itérateurs (le système d'emprunt garantissant qu'il reste valide, par exemple, impossible d’agrandir un Vec si on itère dessus, car cela pourrait invalider l'itérateur).
- Temporal Safety: vérifier par le compilateur.
- Type Safety: on est dans du unsafe.
- Initialization Safety: le langage permet de déclarer des variables sans les initialiser, mais toutes les branches qui la lisent doivent l'initialiser (vérifier par le compilateur). Pour des workflow complexe, on est dans du unsafe.
- Data-Race Safety: en grande partie vérifié par le compilateur via les traits Send et Sync et comment sont construit les primitives de synchro (valeur à l'intérieur de l'objet de synchronisation plutôt qu'a côté).

Alors qu'en C ou C++ il n'y a aucune de ces garanties, que se soit côté compilateur ou la bibliothèque standard, on est tout le temps en mode "unsafe". Même les retours via Option que pourrait adopter la bibliothèque standard sur les accès serait une vaste blague en C++: trop de limitation et de facilité à lire sans vérification en absence de pattern matching (je crois que les propositions se battent toujours sur la syntaxe).

Et il y a aussi la gestion des dépendances, et notamment les modules C++ qui ont mis 23 ans à arriver (depuis la norme 2003 et le fameux export) ... et c'est encore du "bas niveau" avec 1 normalisation du format de précompilation (<- si j'ai bien tout compris)

Tu es sûr pour export de C++03 ? J'ai l'impression que c'était surtout une facilité pour réduire les temps de compilation des templates. Mais avec plein de contrainte. Éjecté en C++11. Après il y a eu des expérimentations par Google sur des modules, un grand vide, puis finalement des propositions pour avoir quelque chose en C++20 que les compilateurs commencent à peine à bien supporter.

Par contre, je n'ai pas souvenir d'une normalisation du format. Pour moi, ce n'était pas voulu, chaque compilateur étant libre de faire comme il veut. Mais j'ai vu passé des trucs sans lire, probablement concernant le mapping source <-> pré-compilé (ça semble assez galère de gérer les dépendances à la main, clang fournit des outils spécifiques pour ça).

Pendant ce temps les autres langages travaillent : [...] la facilité (les bibliothèques standards qui intègrent tellement de trucs, contrairement à la std qui n'a toujours pas de threads (que bas niveau), 18 ans pour avoir les tableaux associatifs et la gestion de l'unicode ), ...

Personnellement, je suis plutôt contre avoir une bibliothèque standard intégrant plein de truc. Plus il y a de domaine couvert par une SL, plus il y a besoin d'expertise. Faire quelque chose qui fonctionne est "facile", mais faire quelque d'efficace l'est beaucoup moins. Je vais prendre les regexes comme exemple.

- Il faut choisir une syntaxe ou un standard. Il y en a 2 assez connu: PCRE et POSIX. À cela s'ajoute toutes les variantes. À partir du moment une syntaxe existe, elle ne peut presque plus évoluer puisque le pattern aurait un comportement différent. Par conséquent, on se trouve lié à la version d'un standard -> évolution lente, problème avec des lib header only.
- Il faut aussi définir quel est le cadre d'utilisation, ce qui va beaucoup influencer l'implémentation (et l'interface). Par exemple, préfère-t-on une recherche en temps constant avec une mémoire stable, quitte à ce qu'elle ne soit pas la plus rapide ou une implémentation le plus rapide possible avec des corners cases ? Pour info, un mauvais pattern avec PCRE peut prendre plusieurs secondes sur un texte d'une centaine de caractères.
- Il faut des personnes compétentes sur le sujet. On peut faire une implémentation triviale, c'est ce qu'à fait libstdc++. Résultat, a* sur quelques milliers de 'a' fait un dépassement de pile.
- Maintenant qu'on a une implémentation, il faut une stabilité de l'ABI (parce que C++...) -> gros frein sur les modifications.

Peaufiner un moteur regex demande beaucoup d'effort, il suffit de voir les gros existant pour s'en convaincre (PCRE2, RE2, hyperscan / vectorscan). Mais c'est pareil pour les parseurs json (nlohmann::json, glaze, daw_json_link, simdjson, etc) et ainsi de suite. Chacun vient avec ses forces et faiblesses, mais en mettant dans le standard, on se retrouve avec quelque chose qui évolue beaucoup plus lentement, beaucoup moins facilement et avec très peu de spécialiste travaillant dessus (voir pas du tout).

En plus, comme cela se voudra à usage général, on se retrouve vite avec quelques choses qui pourrait être beaucoup plus efficace en changeant de lib. Mais si c'est dans le standard, la plupart des dév feront un choix par commodité. À contrario, avec un gestionnaire de lib qui se tient, on peut facilement prendre n'importe quoi par commodité (pas spécialement plus d'effort), mais les mainteneurs de compilateur et le standard ont beaucoup moins de charge de travail.

[ChristianRoberge]

Pourquoi cherche-t-on la facilité? Y-a-t-il "une peur" de devenir un expert en programmation? J'ai 35 ans d'expertise en C++ hautement optimisé et mon constat est le suivant. Un débutant qui cherche la facilité passe forcément à côté des subtilités de la programmation et son expertise ne se développe pas. Ceci est une grave lacune pour un professionnel qui doit viser les hauts standards de qualité. Je suis d'accord avec Mamadou mais pour d'autres raisons. Personnellement, autour des années 2000, je me suis mis véritablement au C++. À l'époque le C++ était plus simple que le Rust présentement, mais aussi beaucoup hasardeux (Pas de libraire standard). Fuite de mémoire et autres problèmes étaient la norme dans mon code. L'utilisation du logiciel "BoundChecker" m'a permis de trouver mes erreurs comme Mamadou le propose. Il a eu des effets de bord important sur mon expertise. Premièrement, la très grande majorité des erreurs m'ont indiqué ce que je faisais d'incorrect. Un coup les erreurs identifiés et comprises, je les répétais plus dans l'avenir (sinon on est un programmeur idiot!). Deuxièmement, les quelques erreurs qui sont survenues après cela ont été causées par des mauvaises pratiques de design logiciel et de meilleures pratiques ont été adoptées. La conséquence est que depuis 15 ans, je n'ai plus de problèmes dans ce type dans mon code et dans celui que je dirige (Note: Merci à la librairie standard!)

Je vois donc des inconvénients majeurs à passer à Rust:
1. Dans mon cas, le Rust ne m'apporte rien de plus que ce que j'ai déjà (Mes programmes sont sécuritaires!).
2. Le langage Rust a une certaine complexité aussi et il évolue rapidement. Ceci complique l'apprentissage des débutants.
3. En C++ moderne, il n'y a techniquement plus de problème. L'époque du C (Malheureusement, toujours intégré et compatible au C++) est révolu et nous devrions plus enseigner le C++ en utilisant le paradigme de la programmation C.
4. Je ne suis pas convaincu qu'en poussant la performance à outrance, nous somme capable d'approcher en Rust, les optimisations du C++. L'introduction du mode "unsafe" en Rust est pour moi un aveu d'échec à le faire (tout au moins c'est une faille énorme dans leur sacro saint principe de sécurité). Pour moi, un langage "safe" ne peut pas avoir de mode "unsafe". Si cela existe, tout le langage est "unsafe" contrairement au prétention de Rust.
5. Enfin le point le plus important pour moi, le design logiciel en C++ est nettement supérieur. La richesse du C++ m'a permis d'utiliser d'utiliser à maintes reprises des agencements qui étaient non documentés et qui à première vue semblait illégal (Merci à Alexandrescu pour son audace et de m'avoir permis de penser autrement). Le langage nounou et strict ne permet pas ce type d'acrobatie. Mon meilleur coup dans un section critique en C++ était une amélioration de plus de 20% en vitesse et près de 10% en mémoire par rapport à un code qui suivait une avenue plus traditionnelle (Un autre programmeur m'a dit que l'on ne pouvait pas faire mieux!)

Pour toute ces raisons, je ne passerai jamais au Rust!

Il y a un inconvénient au C++ que je vie en tant que directeur. L'introduction d'un nouveau membre à l'équipe de programmation exige un formation intense sur notre façon de travailler, concevoir et coder. Cette formation est ardue, spécialement pour un débutant, mais croyez-moi mon expérience, ce temps est un investissement pour lui et la compagnie car les bénéfices à long terme sont immenses.

[Pyramidev]

Pourquoi cherche-t-on la facilité? Y-a-t-il "une peur" de devenir un expert en programmation? J'ai 35 ans d'expertise en C++ hautement optimisé et mon constat est le suivant. Un débutant qui cherche la facilité passe forcément à côté des subtilités de la programmation et son expertise ne se développe pas. Ceci est une grave lacune pour un professionnel qui doit viser les hauts standards de qualité.

De quelle "facilité" te plains-tu dans le cas de Rust ? Le typage sur les durées de vie ? En quoi cela empêcherait-il de devenir un expert en programmation ? C'est un peu comme si un développeur JavaScript qui a appris à déboguer des erreurs de typage trouvait que les langages statiquement typés dont C++ étaient "faciles" car empêchaient certaines erreurs directement à la compilation et s'inquiéterait de l'impact du typage statique sur la montée en compétence des développeurs.

5. Enfin le point le plus important pour moi, le design logiciel en C++ est nettement supérieur. La richesse du C++ m'a permis d'utiliser d'utiliser à maintes reprises des agencements qui étaient non documentés et qui à première vue semblait illégal (Merci à Alexandrescu pour son audace et de m'avoir permis de penser autrement). Le langage nounou et strict ne permet pas ce type d'acrobatie. Mon meilleur coup dans un section critique en C++ était une amélioration de plus de 20% en vitesse et près de 10% en mémoire par rapport à un code qui suivait une avenue plus traditionnelle (Un autre programmeur m'a dit que l'on ne pouvait pas faire mieux!)

Peux-tu donner plus de détails ?

Si je commet une erreur dans mon raisonnement, je suis tout à fait capable d'entendre les arguments contre "ma petit réfexion".
(NdlM : message déplacé dans un fil distinct)

Hélas, je ne comprends pas comment tu as interprété les règles du borrow checker en Rust. Peux-tu donner des exemples sur les points que tu critiques ?

[mintho carmo]

Il y a 20 ans, on expliquait à ceux qui faisaient du C en quoi c'était pertinent de passer au C++. Et ils répondaient avec des arguments... "criticables".

Maintenant, c'est les devs C++ qui défendent leur langage avec les mêmes arguments utilisés par les devs C il y a 20 ans.

Ca me laisse perplexe.

Signé : un dev C++, qui ne veut pas non plus passer à Rust, mais qui n'adhère pas du tout à certains arguments de ceux qui défendent le C++.


"Pourquoi cherche-t-on la facilité?"
"C'est saoulant ce délire du besoin du code parfait."
"Cette sévérité sélective à l'égard du C et C++ sur cette obsession de la gestion mémoire me parait excessive."

Quand je vois ce genre de commentaires, je me dis qu'il est probablement préférable d'imposer un langage avec des contraintes qui imposent la sécurité, plutôt que laisser les devs faire selon leur bon vouloir.

[Luc Hermitte]

Il y a 20 ans, on expliquait à ceux qui faisaient du C en quoi c'était pertinent de passer aux C++. Et ils répondaient avec des arguments... "criticables".

Maintenant, c'est les devs C++ qui défendent leur langage avec les mêmes arguments utilisés par les devs C il y a 20 ans.

Il y a une petite différence, il est relativement aisé d'introduire graduellement des features du C++ dans un code C.

Passer à Rust... il faut repartir de zéro. Perdre des features... Mais oui. On progresse vers plus de sécurité sans sacrifier les perfs contrairement à d'autres langages.

[fdecode]

il faut repartir de zéro. Perdre des features...

Je viens de me plonger dans les évolutions du standard depuis C++11.
Je me suis limité aux grandes lignes, évidemment, mais il y a beaucoup d'équivalence C++ / Rust (je ne parle pas des caractéristiques propres évidentes Class <-> traits, sémantique de prêt, ...).
Pour ce qui est de certaines fonctionnalités rajoutées aux C++, il y a souvent des équivalents qui me paressent mieux en Rust: par exemple le fonctionnel et le pattern matching.
En lien avec les coroutines, il y a en Rust: une bonne prise en charge des évaluations différées ; des fonctionnalités en programmation asynchrone non bloquantes plus abouties, à mon avis, qu'en C++ (notamment des runtimes quasi standards) ; les générateurs sont encore nightly (même s'il y a des crates proposant des alternatives) ; et bien d'autres équivalents aux usages des coroutines. Par contre, la philosophie n'est pas de faciliter l'accès à des fonctionnalité de coroutines générales (pour des raisons de sécurité, d'ailleurs).

Etc.

Ce qui freine l'adoption du langage est certainement le coût d’acquisition d'une compétence équivalente, et les historiques de projets.

[Luc Hermitte]

a- Personnellement, autour des années 2000, [...] À l'époque le C++ était [...] mais aussi beaucoup hasardeux (Pas de libraire standard). Fuite de mémoire et autres problèmes étaient la norme dans mon code.

[...]
3. En C++ moderne, il n'y a techniquement plus de problème. L'époque du C (Malheureusement, toujours intégré et compatible au C++) est révolu et nous devrions plus enseigner le C++ en utilisant le paradigme de la programmation C.

[...]
c- Il y a un inconvénient au C++ que je vie en tant que directeur. L'introduction d'un nouveau membre à l'équipe de programmation exige un formation intense sur notre façon de travailler, concevoir et coder. Cette formation est ardue, spécialement pour un débutant, mais croyez-moi mon expérience, ce temps est un investissement pour lui et la compagnie car les bénéfices à long terme sont immenses.

a- Euh... La lib standard est standard depuis 98... Certes on n'avait pas std::unique_ptr, mais std::auto_ptr (qu'il fallait coupler avec boost::ptr_vector), std::vector, std::string, les flux... Début 2000, boost nous a aussi apporté boost::scoped_ptr et boost::shared_ptr, en attendant la sémantique de déplacement.

3- Oui! Le C++ moderne est ce qui fait toute la différence. Savoir enseigner la cuisine sans passer par la taille du silex parce que c'est comme ça que l'on faisait avant...
J'ai passé je ne sais combien de temps ici et ailleurs, déjà avant 2011, à pousser à rompre avec l'héritage du C pour moderniser notre approche du C++ et son enseignement. Je valide complètement.

Toutefois, on a toujours deux gros soucis non triviaux et non gérés par le langage: les aliasings, et les use-after-move car l'objet existe toujours : il n'est pas `del` comme en Python.
(Après il parait que Rust élimine les data-races, mais je suis sceptique comment le langage peut gérer les races au niveau métier -- ça me fait penser à ces critiques comme quoi les conteneurs de la SL ne sont pas thread-safes alors que la cohérence c'est bien plus subtil qu'ajouter ou retirer un élément. Mais peut-être que je me trompe et qu'il y a un équivalent natif de la preuve de concept d'Andrei Alexandrescu autour des fonctions membres volatiles, qui devait être opt-in)

c- Oui. Il est souvent nécessaire de former.
Après, les formations que je donne en interne sont loin de ne parler que de syntaxe. Je passe beaucoup de temps à reprendre les fondements objets, les bonnes pratiques associées, le besoin de libération déterministe, les contrats VS validation des inputs VS prog défensive... Bref, plein de trucs sans rapport direct avec le C++.

mais le C++ moderne (qui a plus de 10 ans maintenant)

Au moins 22ans: https://www.artima.com/articles/modern-c-style

Après... tous les 3 ans il se modernise encore. Mais la rupture de style (RAII + SL + exploitation du typage), était là il y a déjà longtemps.

A propos ça fait longtemps qu'il y a des sortes de modes "hardened" dans les implémentations de la SL. Mais si je comprends, la différence est que maintenant l'ABI reste compatible selon le mode de défensivité de la SL qui est choisi lorsque l'on compile?

[fdecode]

Après il parait que Rust élimine les data-races

Oui, et c’est précisément là que Rust se distingue : les data races sont éliminées par construction, non pas par ajout d’outils externes ou d’analyse dynamique, mais en intégrant dans la sémantique même du langage la condition d’absence de data race.

Plus précisément, le modèle de propriété et d’emprunt (borrowing) encode formellement ce qu’est une data race :

“Un accès concurrent à une donnée, dont au moins un est mutable”
devient :
“Soit un accès mutable exclusif, soit plusieurs accès immuables, mais jamais les deux à la fois”

Cette règle est vérifiée statiquement par le compilateur, ce qui permet de garantir l’absence de data races sans coût d’exécution, et sans mécanismes comme les verrous implicites ou les analyseurs de course.

[Luc Hermitte]

OK. Je lis que Rust distingue data-race et race-condition. Vu que je range ces erreurs dans le même paquet je comprends pourquoi je ne voyais pas ce que Rust pouvait faire pour moi -- que ma corruption soit logique ou plus profonde, je considère que mon programme ne peut rien produire d'utile, voire qu'il peut tout autant saboter des résultats.

[fdecode]

OK. Je lis que Rust distingue data-race et race-condition. Vu que je range ces erreurs dans le même paquet je comprends pourquoi je ne voyais pas ce que Rust pouvait faire pour moi -- que ma corruption soit logique ou plus profonde, je considère que mon programme ne peut rien produire d'utile, voire qu'il peut tout autant saboter des résultats.

Le data race est une notion formalisée, localisable, et encodable dans un système de types (comme celui de Rust), alors que la race condition, au sens large, est une classe plus générale d’erreurs concurrentes, sans définition universelle ni cadre d’analyse unique.
Les deux sont indécidables en toute généralité, mais Rust, en restreignant le langage par son système de propriété et d’emprunts, rend la détection (et même l’élimination) des data races décidables par construction.

Et c’est peut-être là la vraie logique de Rust :
--> automatiser ce qui est formalisable (data race),
--> laisser la logique métier, l’ordre des événements, et les choix de synchronisation entre les mains du développeur.

[jo_link_noir]

A propos ça fait longtemps qu'il y a des sortes de modes "hardened" dans les implémentations de la SL. Mais si je comprends, la différence est que maintenant l'ABI reste compatible selon le mode de défensivité de la SL qui est choisi lorsque l'on compile?

Cela se veut toujours compatible avec l'ABI, quel que soit le niveau choisi. Et c'est prévu pour être utilisable en production (au moins pour un mode). Des tests Google pour Android, le coût est de 0.8% avec libc++ (je crois d'ailleurs que c'est eux qui l'ont introduit dans clang). Les précédentes manières de faire ont été supprimées côté clang et msstl.

Pour gcc par contre, ça fait effectivement bien longtemps qu'il existe les modes assertion et debug (le dernier cassant l'ABI), mais à ma connaissance, ce n'est pas spécialement pensé pour être utilisable en production et le coût est proche de 10% (de mémoire, je ne me souviens pas où j'avais vu le chiffre). En plus d'être activé si pas d'opti, c'est aussi fait avec la nouvelle option -fhardened qui regroupe plusieurs options (voir --help=hardened avec gcc-15).

Il y a ça, mais je pensais aussi à certaines fonctionnalités comme les contrats (que j'attendais depuis un bout de temps) ; et typiquement le genre de truc qui devrait un max être vérifié de façon statique (compilation ou analyse statique).

Pour les contrats, il n'y en a pas besoin puisqu'on ne peut pas utiliser un générique sans spécifier un trait qui définit son interface. Par contre, la généricité à un certain nombre de limitation comme pas de spécialisation (si on se débrouille bien, le compilateur pointe l'issue ouverte depuis 7 ans) ou pas d'opération avec des constantes (pas possible de faire array</*Len*/10>::drop_last</*N*/3> -> array</*Len-N*/7> à cause de la soustraction). On peut plus ou moins contourner ou faire différemment, mais c'est ce qui m'a le plus embêté sur le petit projet que j'avais.

Pour la vérification statique, il n'y en a pas moins qu'en C++ et le langage ne se traîne pas les casseroles du C.

[Luc Hermitte]

Pour les contrats, il n'y en a pas besoin puisqu'on ne peut pas utiliser un générique sans spécifier un trait qui définit son interface. Par contre, la généricité à un certain nombre de limitation comme pas de spécialisation (si on se débrouille bien, le compilateur pointe l'issue ouverte depuis 7 ans) ou pas d'opération avec des constantes (pas possible de faire array</*Len*/10>::drop_last</*N*/3> -> array</*Len-N*/7> à cause de la soustraction). On peut plus ou moins contourner ou faire différemment, mais c'est ce qui m'a le plus embêté sur le petit projet que j'avais.

Pour la vérification statique, il n'y en a pas moins qu'en C++ et le langage ne se traîne pas les casseroles du C.

Hum... Pas sûr que l'on parle de la même chose. Je parlais des contrats (C++26), pas des concepts. Même s'il y a un rapport lointain où le concept est une sorte de contrat sur le type, les contrats ne sont pas lié à la généricité. Ca peut aller de "le nombre d'éléments stockables est cohérent avec la RAM alloué" (difficile à exprimer) à ce "flottant doit être positif", en passant par "ce pointeur ne doit pas être null si on est en pleine Lune". Sans parler des "je sais que le flottant appartient à [2; 42[".

Mon espoir est que les contrats qui ne seront demain que des asserts sous stéroïdes, puissent être un jour exploités pour faire de l'analyse statique -- même si ce n'est qu'une exploitation partielle. C'est l'intérêt d'une solution standardisée dans le langage et non sous forme de lib, ou d'annotation propriétaire à un outil.

[jo_link_noir]

Hum... Pas sûr que l'on parle de la même chose. Je parlais des contrats (C++26), pas des concepts.

J'ai mal lu .
Du coup non, y a pas.

@OuftiBoy:

ptr + vec, je ne comprends pas l'accumulation. Ni pourquoi un ptr seul à besoin d'être alloué, mais pas un ptr vec. Mais si je comprends bien, vec est builtin, on ne peut pas implémenter vec.add ?

Je rejoins bacelar sur la facilité d'utilisation: un pointeur est une notion compliquée pour un débutant, ce n'est pas simple. Plein de langages se débarrassent du problème en ce reposant sur un GC.