Il n'y en a pas parce que dans quelques temps (p"robablement C++23), il y aura les contrats qui permettront de vérifier les indices au bon endroit (c'est-à-dire dans le code appelant puisqu'avoir un bon indice est une pré-condition). Donc, le comité a décidé de ne pas ajouter une fonction (genre at) qui ne servira plus à rien bientôt.
Ça laisse quand même au minimum entre 2020 et 2023 sans solution sérieuse.
Sur le reste, je ne vois pas trop où tu veux en venir. C++ évolue aussi dans le bon sens. Par exemple, les entiers sont dorénavant considérés comme étant codés en complément à 2, ce qui était une scorie de l'époque où C a été standardisé.
Mais on reste en UB sur overflow. Non plus pour les raisons historiques de l'UB (difference entre 2 procs), mais bien uniquement pour les raisons postmodernes : "opti" (avec les guillemets pour indiquer que c'est avec la technique des transformations valides uniquement sous hypothèse, typiquement non prouvée, d'absence d'UB). Après étant donné l'impact sur le codegen des indexations sur x86, peut-être que cette opti là c'est une des rare que je "veux" peut-être (en compromis)—mais faudrait voir si on peut pas prouver les non débordements au lieu d'en faire l'hypothèse, ainsi que bencher avec/sans. Il y a des bases de code majeures (ex : Linux) qui compilent en fno-strict-overflow ou fwrapv, donc probablement que c'est pas si crucial que ça, en fait.
Depuis C++11, il y a un modèle mémoire pour faire du multithread.
Et il est extrêmement bienvenue, même si on arrivait à faire du multithread avant. Tout comme on arrive à faire de la shm ou du mmap aujourd'hui, alors que dans la machine abstraite c'est pas officiellement prévu. C et C++ avaient ce statut spécial nécessaire pour les langages systèmes ; la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes. La tendance postmoderne des implémenteurs est beaucoup plus de se contenter de la norme et d'ignorer tous les problèmes concrets que cet extrémisme engendre (et rejeter la faute sur les utilisateurs du compilo au lieu d'améliorer la qualité d'implémentation).
il ne faut pas se leurrer, C++ n'est pas fait pour être un langage «safe»
Justement. S'il refuse obstinément de prendre raisonnablement ce tournant, mon hypothèse c'est qu'il va passer de statut de langage système absolument majeur à celui de langage de niche. Et encore. Vu que j'arrive même pas à coder d'allocateur avec sans faire 42 UB formelles par ligne, j'ai du mal à voir quel niche il va finir par occuper : jeu vidéo offline, peut-être. Hm même ça, ça n'existera bientôt plus trop.
[^] # Re: Joli lancer !
Posté par Guillaume Knispel . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 2.
Ça laisse quand même au minimum entre 2020 et 2023 sans solution sérieuse.
Mais on reste en UB sur overflow. Non plus pour les raisons historiques de l'UB (difference entre 2 procs), mais bien uniquement pour les raisons postmodernes : "opti" (avec les guillemets pour indiquer que c'est avec la technique des transformations valides uniquement sous hypothèse, typiquement non prouvée, d'absence d'UB). Après étant donné l'impact sur le codegen des indexations sur x86, peut-être que cette opti là c'est une des rare que je "veux" peut-être (en compromis)—mais faudrait voir si on peut pas prouver les non débordements au lieu d'en faire l'hypothèse, ainsi que bencher avec/sans. Il y a des bases de code majeures (ex : Linux) qui compilent en fno-strict-overflow ou fwrapv, donc probablement que c'est pas si crucial que ça, en fait.
Et il est extrêmement bienvenue, même si on arrivait à faire du multithread avant. Tout comme on arrive à faire de la shm ou du mmap aujourd'hui, alors que dans la machine abstraite c'est pas officiellement prévu. C et C++ avaient ce statut spécial nécessaire pour les langages systèmes ; la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes. La tendance postmoderne des implémenteurs est beaucoup plus de se contenter de la norme et d'ignorer tous les problèmes concrets que cet extrémisme engendre (et rejeter la faute sur les utilisateurs du compilo au lieu d'améliorer la qualité d'implémentation).
Justement. S'il refuse obstinément de prendre raisonnablement ce tournant, mon hypothèse c'est qu'il va passer de statut de langage système absolument majeur à celui de langage de niche. Et encore. Vu que j'arrive même pas à coder d'allocateur avec sans faire 42 UB formelles par ligne, j'ai du mal à voir quel niche il va finir par occuper : jeu vidéo offline, peut-être. Hm même ça, ça n'existera bientôt plus trop.