Dans une réponse du 15 mars à une question d' InfoWorld, Stroustrup a souligné les points forts du C++. « Je trouve surprenant que les rédacteurs de ces documents gouvernementaux semblent ignorer les atouts du C++ contemporain et les efforts déployés pour fournir de solides garanties de sûreté », a déclaré Stroustrup.
Stroustrup a mis en lumière un fait essentiel à la racine du problème :
Il y a deux problèmes liés à la sûreté. Sur les milliards de lignes de C++, peu suivent complètement les directives modernes, et les notions des gens sur les aspects de la sûreté qui comptent diffèrent.
Cela met en évidence un problème significatif du C++. Lorsqu'un langage de programmation permet l'exécution d'actions potentiellement dangereuses, il ne faut pas s'étonner qu'une part considérable de développeurs en fasse mauvais usage.
Et lorsqu'on les confronte à l'écriture de mauvais code, les développeurs avancent divers arguments pour se justifier — qui tiennent souvent plus de l'excuse que de la raison valable :
- Délais serrés: « J'ai dû me dépêcher à cause de délais serrés. Il n'y avait pas assez de temps pour écrire du code propre. »
- Code hérité: « La base de code existante est désordonnée et mal structurée. Mes modifications se fondent simplement dans le désordre ambiant. »
- Dérive du périmètre: « Les exigences n'ont cessé de changer tout au long du projet, ce qui rendait difficile de maintenir un code propre. »
- Contraintes technologiques: « La pile technologique que nous utilisons ne se prête pas à l'écriture d'un code propre. Nous sommes limités par ce que nous avons. »
Alors oui, les développeurs ont la responsabilité de s'assurer qu'ils écrivent correctement leur code C++. Cependant, ce genre d'approche pourrait s'avérer risqué pour l'avenir du C++. Il y a quelques années, nous avons assisté au déclin de Nokia. En effet, la chute de Nokia — de premier fabricant mondial de téléphones mobiles à acteur en difficulté sur le marché — est une histoire marquée par plusieurs facteurs et erreurs stratégiques. L'une des erreurs critiques de Nokia fut sa décision de s'en tenir trop longtemps à son système d'exploitation Symbian. Si Symbian fut jadis une plateforme dominante, il a peiné à rivaliser avec l'expérience utilisateur offerte par iOS et Android.
En C++, nous nous sommes reposés trop longtemps sur les mécanismes actuels de gestion de la mémoire, et aucune solution radicale n'a été proposée — seulement quelques améliorations que les développeurs doivent appliquer.
Stratégie C++ contre stratégie .NET:
C# a été développé en 2000 principalement pour les machines Windows. Miguel de Icaza a créé Mono pour permettre son utilisation sur Linux et macOS. Cependant, après plus d'une décennie d'utilisation majoritaire du framework .NET standard sous Windows, un problème important est apparu concernant la portabilité du langage. Pour y remédier, Microsoft a collaboré avec Miguel pour créer .NET Core, un sous-ensemble de .NET conçu pour fonctionner sur d'autres systèmes d'exploitation.
Ce n'était pas une solution incrémentale au problème de portabilité, mais une solution radicale, même si une partie du code hérité était incompatible. À l'époque, Miguel de Icaza a décrit .NET Core comme une «version repensée de .NET reposant sur une version simplifiée des bibliothèques de classes », et Immo Landwerth, de Microsoft, a expliqué que .NET Core serait «le fondement de toutes les futures plateformes .NET».
En définitive, cette solution a très bien fonctionné : .NET Core s'est largement répandu, et le grand problème de portabilité a été résolu.
Pourquoi ne pas adopter une approche similaire avec le C++ pour traiter les préoccupations de sûreté de manière plus décisive ? Pourquoi ne pas développer un sous-ensemble sûr du C++ et offrir la possibilité de travailler avec ce sous-ensemble via le compilateur ?
clang --safeConclusion:
Si le C++ continue de permettre aux développeurs d'adopter des pratiques mémoire non sûres, cette importante préoccupation de sûreté persistera, ce qui pourrait conduire à préférer d'autres langages comme Rust ou Go pour les nouveaux projets. Il est peut-être temps d'envisager une solution plus radicale plutôt que de compter uniquement sur des améliorations incrémentales. Certes, l'expérience a démontré que malgré la disponibilité de fonctionnalités modernes en C++ destinées à répondre aux préoccupations de sûreté depuis plus de dix ans, le problème persiste parce que le langage continue d'autoriser les pratiques héritées non sûres.