Tu commence bien en coupant ma phrase... M'enfin bref...
La norme a été finalisée en 2011 mais elle a été discutée pendant des années et une grosse partie des fonctionnalités était déjà implémentée dans les compilateurs.
C'est exactement ce que je dis dans ce que tu as remplacer par "...".
Non, le C++ est juste un outil avec des avantages et des inconvénients.
Si il l'est et Serge sans paille nous le montre régulièrement.
Cet interfaçage demande à faire une couche de translation C ou C++98 vers C++11. Hors ces 3 langages sont presque totalement compatibles donc il est assez subtile de s'assurer que l'on ne leak pas du C dans le reste de ton programme.
Oui c'est le principe de la compatibilité. Si tu veux compiler du C ou du C++98 directement dans du C++11, tu peux. Si tu veux interfacer proprement, tu peux. Tu aurais voulu quoi ? Que le C++11 interdise tout code antérieur et demande de tout réécrire en Rust ? Quand tu appelles du code C depuis le FFI, Rust ne vérifie pas non plus magiquement que ce code est sûr.
Il pourrait très bien me permettre de compiler certains fichiers dans un mode compatible C/C++98 et compiler le reste dans un mode strict. J'ai pas besoin que ce soit le compilateur ça peut être un outil qui répond 1 ou 0 et ça me permettrais de maitriser où est-ce que j'utilise ou non des fonctionnalités particulièrement dangereuse (soit pour m'assurer que c'est limité soit pour switcher progressivement de l'un vers l'autre). Ça ne casse en rien la compatibilité le code généré peut être identique c'est juste dans les étapes de vérifications qu'il y a une différence.
Je ne sais pas ce que tu appelles bugs mais cppcheck est capable de détecter des problèmes comme les fuites mémoires. Je ne pense pas que ce soit fiable à 100% cependant.
Il ne te dis pas que là tu devrait utiliser du RAII.
Interdire des fonctionnalités n'est pas la "façon de penser" de C++ et ça casserait la compatibilité.
C'est ce que les développeurs font ! Les développeurs C++ s'interdisent des pans de la norme pour certains les exceptions pour d'autres les pointeurs nus. Que ce soit fait par le compilateur ou un quelconque outil d'analyse statique je m'en fous, mais si ça n'est pas outillé c'est à la responsabilité des développeurs et c'est forcément moins fiable que si c'était un outil.
De plus les compilateurs ne se gênent pas pour ajouter de nouveaux warning ce qui peu potentiellement ça suffirait amplement. Toujours pas besoin de casser la compatibilité.
Oui c'est vrai. Et c'est le cas de tous les langages qui autorisent du bas niveau, même de Rust en unsafe. Maintenant on peut en discuter des heures mais il n'y a pas de langage parfait (à part haskell installé par nix sur minix, bien-sûr), il faut forcément faire des compromis qui forcément ne plairont pas à tout le monde.
Bla bla bla. Les autres aussi ne sont pas parfait donc on a le droit de... Bref
La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur, s'assurer qu'il le fait bien est un travaille continue de l'équipe. Là où un énorme paquet de langage vont faire quelques trucs pour te contraindre (être plus sécurisés par défaut, t'obliger à écrire juste avant « attention je suis peut être entrain de faire une grosse connerie ici ! », etc). Si tu ne souhaite pas voir l'importante différence qu'il y a entre ces approches, c'est dommage.
Mais se poser la question de comment industrialiser la qualité d'une base de code ce n'est pas insulter le langage, hein ?
[^] # Re: Les avantages de C++ ne sont pas bien différentes avec Rust
Posté par barmic . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3.
Ça va les sophismes...
Tu commence bien en coupant ma phrase... M'enfin bref...
C'est exactement ce que je dis dans ce que tu as remplacer par "...".
Si il l'est et Serge sans paille nous le montre régulièrement.
Il pourrait très bien me permettre de compiler certains fichiers dans un mode compatible C/C++98 et compiler le reste dans un mode strict. J'ai pas besoin que ce soit le compilateur ça peut être un outil qui répond 1 ou 0 et ça me permettrais de maitriser où est-ce que j'utilise ou non des fonctionnalités particulièrement dangereuse (soit pour m'assurer que c'est limité soit pour switcher progressivement de l'un vers l'autre). Ça ne casse en rien la compatibilité le code généré peut être identique c'est juste dans les étapes de vérifications qu'il y a une différence.
Il ne te dis pas que là tu devrait utiliser du RAII.
C'est ce que les développeurs font ! Les développeurs C++ s'interdisent des pans de la norme pour certains les exceptions pour d'autres les pointeurs nus. Que ce soit fait par le compilateur ou un quelconque outil d'analyse statique je m'en fous, mais si ça n'est pas outillé c'est à la responsabilité des développeurs et c'est forcément moins fiable que si c'était un outil.
De plus les compilateurs ne se gênent pas pour ajouter de nouveaux warning ce qui peu potentiellement ça suffirait amplement. Toujours pas besoin de casser la compatibilité.
Bla bla bla. Les autres aussi ne sont pas parfait donc on a le droit de... Bref
La gestion de la mémoire en C++ est dangereuse particulièrement car l'utilisation correcte du RIAA est à la charge du développeur, s'assurer qu'il le fait bien est un travaille continue de l'équipe. Là où un énorme paquet de langage vont faire quelques trucs pour te contraindre (être plus sécurisés par défaut, t'obliger à écrire juste avant « attention je suis peut être entrain de faire une grosse connerie ici ! », etc). Si tu ne souhaite pas voir l'importante différence qu'il y a entre ces approches, c'est dommage.
Mais se poser la question de comment industrialiser la qualité d'une base de code ce n'est pas insulter le langage, hein ?