C'est un point qui me paraît effectivement très dommage dans le design du C++. Ecrire du code fragile est rendu plis facile qu'écrire du code robuste. On peut comparer à Rust qui opte pour la sécurité par défaut et permet d'ôter certaines protections en les identifiants clairement (unsafe, type dédiés, etc ...).
C'est deux approches opposé:
Rust est safe par défaut, unsafe on demand.
C++ est unsafe par défaut, mais te donne des primitives safes à la demande du programmeur.
La première approche fait confiance au compilateur, la deuxième approche fait confiance au programmeur.
J'aurai tendance à dire que la première approche (Rust) semble plus logique sur le papier et plus approprié à du développement où la sécurité compte.
[^] # Re: Performances vs. Sécurité
Posté par Firwen (site web personnel) . En réponse au journal Le glissement du C++ (et dans une moindre mesure du C) vers une position indésirable. Évalué à 4.
C'est deux approches opposé:
La première approche fait confiance au compilateur, la deuxième approche fait confiance au programmeur.
J'aurai tendance à dire que la première approche (Rust) semble plus logique sur le papier et plus approprié à du développement où la sécurité compte.
Mais à en croire pas mal de retours de blogueurs, l'approche de Rust peut aussi se révéler passablement pénible quand le modèle mémoire ne s'y prette pas ( Graph avec multitude de relations mutuelles ( https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/ ) ) ou quand obtenir la performance requise s'associe avec se battre avec la bound checking du compiler ( https://www.reidatcheson.com/hpc/architecture/performance/rust/c++/2019/10/19/measure-cache.html )