Re: Rust vs Go

Peut être un mauvais choix. Des problèmes existent dans C++, il y en a d'autres des manipulations de mémoire risquées comme strcpy(3) (à moins qu'il ai lui aussi était retiré ?). Tu peut toujours faire un newnon protégé. Que le langage apporte aujourd'hui des outils pour faire du code de très grande qualité c'est une évidence, mais il ne déprécie pas tous les anciens usages dangereux. Est-ce que C++14 va déprécier les mots-clef new et delete, le fait qu'il existe d'autres manière de faire n'en fait pas un langage sûr ça permet au développeur de créer des programmes sûre (un peu comme en C quand les développeurs d'OpenBSD je crois s'interdisent l'utilisation de malloc(3) et de quelques autres méthodes pour les remplacer par les leur plus sûre).

Si on considère que le C++ n'était pas fiable et qu'il l'ai maintenant, il ne faut pas parler des nouveautés, mais de ce qui y a était retiré.

Pour mettre en valeur la meilleure sûreté de rust, tu devrais nous donner des exemples où la meilleure analyse statique de rust permet d'éviter des erreurs subtiles et plausibles (Thom le fait un peu plus bas).

Le problème c'est que je ne parlais pas de rust (que je ne connais pas), mais répondais uniquement à ce paragraphe que je citais :

Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute.

qui ne parle que de C++.

Mais grosso modo, pour que C++ soit plus sûr il faudrait qu'en plus d'avoir ajouté les pointeurs géré, ils ai interdit l'utilisation des pointeurs nus. Ce n'est pas le cas.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)