IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2017
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2017
    Messages : 11
    Points : 16
    Points
    16
    Par défaut du calme du calme
    on s'éloigne du sujet dans ce débat..

    un langage peut avoir des soucis de sécurité, mais pour ce qui est de la mémoire, le problème se situe généralement entre la chaise et le clavier..

    si un dev ne comprend pas les buffer overflows => on sait tous quoi en déduire
    si un dev ne comprend pas qu'il faut gérer tous les cas de figure en programmation, meme des attaques => bah ... tant pis

    de mon point de vue (qui vaut ce qu'il vaut, on est d'accord), avant de se dire qu'il faut changer de langages, il faut déjà maitriser les tenants et les aboutissants car des petits malins trouveront toujours un moyen de lever un exploit, meme sur des langages dits "sécurisés" dixit la NSA


    sinon assez d'accord, faire confiance à la NSA en terme de conseil .. échelon toussa ("on a vu que vous utilisiez des langages pas sécurisés, ah et d'ailleurs, il y a des bugs de votre appli, tel fichier telle ligne ")

  2. #22
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 839
    Points : 51 441
    Points
    51 441
    Par défaut Bjarne : « La sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++ »
    « La sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++ », d’après Bjarne Stroustrup
    qui réagit à une sortie de la NSA qui exclut le C++ des langages sécurisés

    Mark Russinovich de Microsoft a déclaré au troisième trimestre de l’année précédente que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve désormais contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

    En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

    « Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

    Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.


    L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    #include <type_traits>
    #include <utility>
    #include <assert.h>
    #include <stddef.h>
    enum NoRefs {};
    enum HasMutRef {};
    enum HasRefs {};
    template <class T, typename Mode>
    class Own;
    template <class T>
    class MutRef;
    template <class T>
    class Ref;
    template <class T, typename... Args>
    inline Own<T, NoRefs> make(Args... args) {
      return Own<T, NoRefs>(std::forward<Args>(args)...);
    }
    template <class T>
    inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) {
      return Own<T, NoRefs>(std::move(own));
    }
    template <class T>
    inline Own<T, NoRefs> consume(Own<T, HasRefs> own) {
      return Own<T, NoRefs>(std::move(own));
    }
    template <class T>
    std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) {
      T* t = own.t_;
      own.t_ = nullptr;
      return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t));
    }
    template <class T>
    std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) {
      T* t = own.t_;
      own.t_ = nullptr;
      return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t));
    }
    // No refs exist.
    template <class T>
    class [[clang::trivial_abi]] Own<T, NoRefs> {
     public:
      template <typename... Args>
      Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {}
      ~Own() { delete t_; }
      Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; }
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
     private:
      friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref);
      friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own);
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own);
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      Own(Own<T, HasMutRef>&& own) : t_(own.t_) {}
      Own(Own<T, HasRefs>&& own) : t_(own.t_) {}
      T* t_;
    };
    // A mut ref exists.
    template <class T>
    class [[clang::trivial_abi]] Own<T, HasMutRef> {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
     private:
      friend class Own<T, NoRefs>;
      Own(T* t) : t_(t) {}
      ~Own() {}
      T* t_;
    };
    // Non-mut refs exist.
    template <class T>
    class [[clang::trivial_abi]] Own<T, HasRefs> {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      Ref<T> ref() { return Ref<T>(t_, &count_); }
     private:
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      explicit Own(T* t) : t_(t) {}
      ~Own() { assert(count_ == 0u); }
      T* t_;
      uint32_t count_;
    };
    template <class T>
    class MutRef {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      ~MutRef() = default;
      MutRef(MutRef&& other) : t_(other.t_) {}
     private:
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own);
      MutRef(T* t) : t_(t) {}
      T* t_;
    };
    template <class T>
    class Ref {
     public:
      T& operator*() const noexcept { return *t_; }
      T* operator->() const noexcept { return t_; }
      ~Ref() { --(*count_); }
      Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); }
      Ref(Ref&& other) : t_(other.t_), count_(other.count_) {}
     private:
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own);
      Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); }
      T* t_;
      uint32_t* count_;
    };
    MutRef<int> Borrows(MutRef<int> i) {
      (*i)++;
      return i;
    }
    TEST(Borrow, HelloWorld) {
      // Can't do this. The HasMutRefs type is not destructible outside of
      // consume()in order to have compiler check it is re-owned, but it won't
      // compile. To pass the HasMutRefs to consume() it has to be destroyed both
      // inside and outside of consume(). This is true even if trivial_abi is
      // used and only one destructor would actually run.
      Own<int, NoRefs> i = make<int>(5);
      auto& hasmut = mut(std::move(i));
      MutRef<int> ref = Borrows(std::move(hasmut.second));
      Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref));
    }

    La sortie de Bjarne Stroustrup intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

    Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

    Sources : Bjarne, Google

    Et vous ?

    Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
    Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
    Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

    Voir aussi :

    L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
    Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
    C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #23
    Membre régulier
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mai 2013
    Messages
    32
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2013
    Messages : 32
    Points : 93
    Points
    93
    Par défaut
    je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets. L'un via les constructeurs et l'autre via les implementations de traits

  4. #24
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 470
    Points : 6 106
    Points
    6 106
    Par défaut
    Citation Envoyé par Padget Voir le message
    je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets.
    Pour la gestion de la mémoire, le C++ offre la possibilité d'utiliser le RAII qui évite les double free et permet aux éventuelles fuites de mémoire de ne pas être plus fréquentes que dans un langage avec ramasse-miettes.

    Il y a des développeurs C++ qui sous-utilisent le RAII et introduisent plein de fuites de mémoire, ce qui est un problème culturel autour de l'apprentissage du C++.

    Cependant, le C++ n'empêche pas à la compilation les dandling references/pointers/iterators. Par exemple, si on garde une référence vers un élément d'un vecteur, puis que l'on fait un push_back, que ce dernier oblige de déplacer ailleurs en mémoire les éléments du vecteur, puis que l'on essaie d'accéder à ce vers quoi pointe la dandling reference, cela ne provoque pas d'erreur de compilation, contrairement à Rust. Le C++ n'a pas autant de contrôles à la compilation qu'en Rust.

    Idem pour le multithreading : le C++ ne fait pas de contrôle à la compilation contre les accès concurrents.

    Le C++ n'a pas le borrow checker de Rust. Pour les contrôles à la compilation, ces deux langages ne sont clairement pas au même niveau.

  5. #25
    Membre averti
    Profil pro
    Développeur
    Inscrit en
    Octobre 2008
    Messages
    122
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Octobre 2008
    Messages : 122
    Points : 425
    Points
    425
    Par défaut
    Hebe, il va pas bien Bjarne ou quoi? Il a oublie que C++ a besoin des sanitizers pour ne meme pas arriver au niveau du borrow checker de rust?
    Bon, il defend son bout de pain apres, il perd pas le nord, mais bon de la a dire des trucs pareil je sais pas trop..

  6. #26
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 741
    Points
    3 741
    Billets dans le blog
    12
    Par défaut
    Bjarne Stroustrup est sans conteste un immense contributeur au monde du développement informatique, mais il défend son bébé qui... conserve ses défauts.

    J'ai commencé l'informatique avec C++, touché à bien des langages, et je reconnais les qualités de Rust malgré ses défauts comme le temps de compilation et le manque de lib. Pour moi Rust est un pas en avant, il est ce que C++ a essayé d'être si C++ n'avait pas essayé de rester rétro-compatible avec C dans un premier temps, puis avec lui-même. Je vois les efforts de Herb Sutter, il essaye d'améliorer C++ avec "CppFront" mais même avec ça on n'arrive pas au niveau des exigences de Rust en terme de null-safe, memory-safe, thread-safe
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  7. #27
    Membre régulier
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mai 2013
    Messages
    32
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2013
    Messages : 32
    Points : 93
    Points
    93
    Par défaut
    Certes mais ça reste mon scalpel préféré pour faire du code 😊

  8. #28
    Membre émérite
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    909
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 909
    Points : 2 818
    Points
    2 818
    Par défaut
    Bah pour lui j'imagine qu'il peut vraiment coder aussi bien en C++ qu'un expert en Rust.

    Mais quid du développeur... "moyen" ? (un vrai développeur quand même)

  9. #29
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 493
    Points
    15 493
    Par défaut
    C'est a rapprocher du récent document de Bjarne Stroustrup en tant que membre du groupe de direction de l'ISO C++ : https://www.open-std.org/jtc1/sc22/w...23/p2759r0.pdf

    On voit bien qu'il est pris de court par le tournant actuel de l'industrie vers une sécurisation par défaut, qu'il n'a pas du tout anticipé, et dont il a encore du mal à admettre l'importance. On voit qu'il a tendance à réduire le problème au fait que le C++ devrait mieux communiquer sur ses fonctionnalité de sécurité. Il peine à cerner ce qu'est exactement Rust et ce qu'il apporte(approximations, exemples mal choisis, ...). Après avoir passé une grande partie du document a minimiser le problème, il ébauche quand même un chemin vers une vraie sécurisation du C++, mais on voit bien qu'ils sont encore loin ne serait-ce que d'un embryon de solution consensuelle.

  10. #30
    Membre régulier
    Profil pro
    Inscrit en
    Août 2006
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 79
    Points : 124
    Points
    124
    Par défaut
    Ok le borrow-checker c'est top...
    mais quid du paradigme TRAIT ?
    je trouve ca plus souple que la poo.

  11. #31
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 043
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 043
    Points : 2 234
    Points
    2 234
    Par défaut
    Sans attendre l'ISO et Stroustrup. La communauté C++ à la chance d'être une des plus compétentes avec des décennies d'expériences.

    Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.

    L'équipe de Clang commence déjà a proposer des solutions.
    https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
    Homer J. Simpson


  12. #32
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 493
    Points
    15 493
    Par défaut
    Citation Envoyé par foxzoolm Voir le message
    Ok le borrow-checker c'est top...
    mais quid du paradigme TRAIT ?
    je trouve ca plus souple que la poo.
    C'est vrai que les traits sont une fonctionnalité indiscutablement au cœur de Rust tout aussi importante sinon plus que le borrow checker. Je dirais aussi que les enum sont au moins aussi importante. Mais le sujet c'est la sécurité, et pour le coup, ça n'est ni les trait ni les enums qui font la sécurisation du Rust.
    Ce qui fait sa sécurisation mémoire comparé au C++, c'est principalement le borrow checker et des choix par défaut sécurisés (initialisation obligatoire des variables, contrôles de dépassement, ...)

    Citation Envoyé par Astraya Voir le message
    Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.
    C'est pas les initiatives qui manquent pour améliorer la sécurité du C++, mais la difficulté c'est de faire quelque chose qui, à la fois :
    • soit vraiment efficace
    • s’intègre bien a la syntaxe du langage
    • marche bien avec la base de code existante
    • est acceptable pour des utilisateurs qui n'ont jamais eu de contraintes fortes jusqu’à présent

    La plupart des initiatives que j'ai vu pèchent lourdement sur un ou plusieurs de ces points.
    L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.

    Citation Envoyé par Astraya Voir le message
    L'équipe de Clang commence déjà a proposer des solutions.
    https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377
    C'est intéressant ça. Pour le coup ça a l'air complétement calqué sur le système des lifetimes de Rust. Reste a voir ce que ça pourra donner en pratique.

  13. #33
    Membre émérite
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    909
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 909
    Points : 2 818
    Points
    2 818
    Par défaut
    Citation Envoyé par Uther Voir le message
    L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.
    .
    Ca me fait penser au passage de Python 2 à Python 3 ou en tout cas un exemple de ce qui peut arriver sur une évolution de langage "brutale".

  14. #34
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 839
    Points : 51 441
    Points
    51 441
    Par défaut Les agences Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust
    Les Agences des Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust
    Qui « offre de meilleures garanties de sécurisation des plages mémoire des logiciels»

    Faut-il arrêter d’initier de nouveaux projets en C++ et passer à Rust ? La question divise dans la communauté des développeurs dont certains recommandent le langage Rust plutôt que le C ou le C++. Les raisons : la parité du Rust en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec une sortie des agences de l’alliance Five Eyes. Elles insistent pour que les organisations abandonnent C++ pour le langage Rust, ce, après que la prise de position du créateur du langage C++ selon laquelle : « la sécurisation des logiciels par le Rust n’est pas supérieure à celle offerte par le C++. »

    Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire.

    La publication des Five Eyes ne s’en écarte pas : « Les langages de programmation tels que C et C++ sont des exemples de langages de programmation qui peuvent conduire à un code non sûr pour la mémoire et qui sont encore parmi les langages les plus utilisés aujourd'hui. Pour tenter d'atténuer les dangers du code à mémoire non sécurisée obtenu en C et C++, de nombreux fabricants de logiciels investissent dans des programmes de formation à l'intention de leurs développeurs.

    Nombre de ces programmes de formation comprennent des tactiques conçues pour réduire la prévalence des vulnérabilités de sécurité de la mémoire produites par ces langages. En outre, il existe de nombreux programmes de formation organisés par des associations commerciales et industrielles. En outre, diverses organisations et universités proposent des formations et un certificat professionnel pour démontrer la connaissance des pratiques de codage sécurisé en C et en C++.

    Bien que la formation puisse réduire le nombre de vulnérabilités qu'un codeur peut introduire, étant donné l'omniprésence des défauts de sécurité de la mémoire, il est presque inévitable que des vulnérabilités de sécurité de la mémoire se produisent encore. Même les développeurs les plus expérimentés introduisent des bogues desquels peuvent résulter des vulnérabilités importantes. La formation doit servir de transition pendant qu'une organisation met en œuvre des contrôles techniques plus robustes, tels que des langages à sécurité mémoire. »

    « Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe », indique l'éditeur RisingWave à propos de la réécriture de son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++.

    C’est une sortie qui fait suite à celle d’Amazon qui est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. » En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.

    Nom : 1.png
Affichages : 36019
Taille : 201,9 Ko

    Néanmoins, Bjarne Stroustrup s’inscrit en faux avec le fait que les comparatifs entre Rust et C++ limitent la notion de sécurisation des logiciels à celle de sécurisation de la mémoire : « Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique. » Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

    Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui
    garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.


    L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

    Code Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    #include <type_traits> 
    #include <utility> 
    #include <assert.h> 
    #include <stddef.h> 
    enum NoRefs {}; 
    enum HasMutRef {}; 
    enum HasRefs {}; 
    template <class T, typename Mode> 
    class Own; 
    template <class T> 
    class MutRef; 
    template <class T> 
    class Ref; 
    template <class T, typename... Args> 
    inline Own<T, NoRefs> make(Args... args) { 
      return Own<T, NoRefs>(std::forward<Args>(args)...); 
    } 
    template <class T> 
    inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { 
      return Own<T, NoRefs>(std::move(own)); 
    } 
    template <class T> 
    inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { 
      return Own<T, NoRefs>(std::move(own)); 
    } 
    template <class T> 
    std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { 
      T* t = own.t_; 
      own.t_ = nullptr; 
      return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); 
    } 
    template <class T> 
    std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { 
      T* t = own.t_; 
      own.t_ = nullptr; 
      return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); 
    } 
    // No refs exist. 
    template <class T> 
    class [[clang::trivial_abi]] Own<T, NoRefs> { 
     public: 
      template <typename... Args> 
      Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} 
      ~Own() { delete t_; } 
      Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } 
      T& operator*() const noexcept { return *t_; } 
      T* operator->() const noexcept { return t_; } 
     private: 
      friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); 
      friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); 
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
      Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} 
      Own(Own<T, HasRefs>&& own) : t_(own.t_) {} 
      T* t_; 
    }; 
    // A mut ref exists. 
    template <class T> 
    class [[clang::trivial_abi]] Own<T, HasMutRef> { 
     public: 
      T& operator*() const noexcept { return *t_; } 
      T* operator->() const noexcept { return t_; } 
     private: 
      friend class Own<T, NoRefs>; 
      Own(T* t) : t_(t) {} 
      ~Own() {} 
      T* t_; 
    }; 
    // Non-mut refs exist. 
    template <class T> 
    class [[clang::trivial_abi]] Own<T, HasRefs> { 
     public: 
      T& operator*() const noexcept { return *t_; } 
      T* operator->() const noexcept { return t_; } 
      Ref<T> ref() { return Ref<T>(t_, &count_); } 
     private: 
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
      explicit Own(T* t) : t_(t) {} 
      ~Own() { assert(count_ == 0u); } 
      T* t_; 
      uint32_t count_; 
    }; 
    template <class T> 
    class MutRef { 
     public: 
      T& operator*() const noexcept { return *t_; } 
      T* operator->() const noexcept { return t_; } 
      ~MutRef() = default; 
      MutRef(MutRef&& other) : t_(other.t_) {} 
     private: 
      friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
      MutRef(T* t) : t_(t) {} 
      T* t_; 
    }; 
    template <class T> 
    class Ref { 
     public: 
      T& operator*() const noexcept { return *t_; } 
      T* operator->() const noexcept { return t_; } 
      ~Ref() { --(*count_); } 
      Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } 
      Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} 
     private: 
      friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
      Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } 
      T* t_; 
      uint32_t* count_; 
    }; 
    MutRef<int> Borrows(MutRef<int> i) { 
      (*i)++; 
      return i; 
    } 
    TEST(Borrow, HelloWorld) { 
      // Can't do this. The HasMutRefs type is not destructible outside of 
      // consume()in order to have compiler check it is re-owned, but it won't 
      // compile. To pass the HasMutRefs to consume() it has to be destroyed both 
      // inside and outside of consume(). This is true even if trivial_abi is 
      // used and only one destructor would actually run. 
      Own<int, NoRefs> i = make<int>(5); 
      auto& hasmut = mut(std::move(i)); 
      MutRef<int> ref = Borrows(std::move(hasmut.second)); 
      Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref));
    }

    La sortie des agences Five Eyes intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

    Après 31 ans, un deuxième langage a fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

    Source : Five Eyes

    Et vous ?

    Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
    Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
    Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

    Voir aussi :

    L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
    Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
    C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  15. #35
    Membre expert

    Profil pro
    activité : oui
    Inscrit en
    Janvier 2014
    Messages
    1 260
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : activité : oui

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 260
    Points : 3 403
    Points
    3 403
    Par défaut
    La comparaison de Rust face à C++ m'a toujours paru assez fallacieuse :
    Je la vois toujours évoqué sans tenir compte de l'écosystème du développeur, à croire que ces 2 langages sont comparés nus.

    Comparer un langage qui tire parti d'un complément de fonctionnalités par des outils externes, à un autre qui en incorpore certaines en natif, mais le faire sans ces dit outils a-t-il du sens ?


    Dans un second temps, Bjarne Stroustrup rappelait à l'occasion de la cppCon 2023 (billet dvp.com du 6 octobre ici) que la question de la sécurité (et la sûreté) n'a pas démarré il y a quelques années, et que les principales règles de codage qui gouverne la sécurité par le code existent depuis au minimum les années 90.
    Depuis cette époque la problématique n'a pas changé --> le difficulté n°1 est de trouver une solution pour que la masse des développeurs aient connaissance de ces règles, la difficulté n°2, qu'ils finissent par avoir l'habitude de les appliquer.
    La difficulté n°2 vient du fait que l'on code avant tout pour répondre à un besoin pratique, et que parmi tous les aspects à traiter sur les concepts à choisir et leur implémentation, les développeurs finissent par oublier d'appliquer certaines notions de sécurité. En découle des erreurs types, comme :
    Les erreurs de logique - où ce qui est écrit s'écarte de la manière dont le codeur le pensait (ex : utiliser '<' là où '>' était pensé)
    les fuites de ressources
    les erreurs de concurrence
    les erreurs de typage
    les overflow et les conversions implicites
    les erreurs de timing - ex : coder un retour à 1,2 ms à un périphérique qui répond aux évènements externe en 1 ms max
    les allocations non prédictibles
    les erreurs d'arrêt -


    NB : pour les diapos de la conférence : lien_github
    NB : pour la conférence :


    Il rappel également que bien qu'une alternative soit "memory safety", ce n'est pas suffisant, la sécurité doit être traité globalement, sur tous ses aspects.
    Une question revient alors assez souvent : si Rust permet plus facilement de produire du code "memory safety" pour une plus grande part de développeurs, Rust permet-il d'atteindre un plus haut degré final de sécurité ?
    Que la réponse soit "oui" ou "non", Rust permet-il à un plus grand nombre de développeurs de produire du code plus sûr ?
    A cette dernière question, je pense pouvoir dire "oui", car permet de le faire de manière plus accessible tous niveaux de maîtrise confondu.

    Une chose est sûr : l'aspect déterministe du code produit en Rust semble être l'un des atouts majeur en terme de garantie sur la sécurité du code produit et son analyse.
    Mais je constate aussi que beaucoup de code produit sont lourd à l'exécution (mémoire, CPU...) parce que le code n'est pas suffisamment verbeux (explicitement écrit).
    Un exemple flagrant, lors d'une démonstration par Jason Turner à la cppCon 2016, où après avoir fait un mapping des couleurs, il faisait face à un overhead.
    Une simple transformation de " static std::array<Color, 16> colors {{... " en " static const std::array<Color, 16> colors {{... " et ses 354 instructions d'assembleur se transforment tout à coup en 7 instructions.
    La conférence cppCon 2016 : lien_youtube
    Pensez à utiliser les pouces d’appréciation, pour participer à la visibilité de l'apport d'un propos, ou l'intérêt que vous y prêtez... qu'il soit positif ou négatif.

  16. #36
    Membre à l'essai
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juin 2021
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Juin 2021
    Messages : 6
    Points : 21
    Points
    21
    Par défaut
    On aimerait bien que les personnes qui osent sortir un avis aussi tranché aient codé au minimum une application en langage Rust. Parce que si programmer (correctement) en C++ (1X/2X) réclame des compétences sérieuses et un investissement important, alors programmer en Rust est autrement plus délicat. En fait il faut expérimenter ce langage incroyablement verbeux pour comprendre sa douleur.

  17. #37
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 470
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 470
    Points : 6 106
    Points
    6 106
    Par défaut
    Citation Envoyé par Regulus136 Voir le message
    En fait il faut expérimenter ce langage incroyablement verbeux pour comprendre sa douleur.
    Je peux comprendre que Rust soit qualifié de verbeux par rapport à du Python. Mais, qualifier Rust d'"incroyablement verbeux" par rapport à C++, cela m'étonne. Il y a des choses plus concises en C++ et d'autres plus concises en Rust. Aurais-tu un exemple de code "incroyablement verbeux" en Rust sous la main à partager ?

  18. #38
    Membre éclairé Avatar de seedbarrett
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2014
    Messages
    191
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2014
    Messages : 191
    Points : 793
    Points
    793
    Par défaut
    Les agences Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust
    Quand je lis ça, j'ai plutôt envie de rester sur C++

  19. #39
    Membre régulier
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 25
    Points : 90
    Points
    90
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Mais, qualifier Rust d'"incroyablement verbeux" par rapport à C++, cela m'étonne.
    Moi aussi, ça m'étonne. En ce qui me concerne, je trouve que ce langage permet de produire du code élégant, et surtout j'aime la manière dont il permet de structurer les librairies dans une perspective de généricité.

    Ceci-dit, les contraintes liées aux sémantiques d'emprunt et de durée de vie peuvent parfois demander un certain exercice intellectuel si on veut aboutir à un code léger.

    Et si on se laisse aller à utiliser les puissants paradigmes de rust n'importe comment, on peut aussi produire du code un peu lourd (e.g. des codes génériques avec des contraintes sur les variables de type un peu dans tous les sens...).

    Il faut aussi programmer avec la philosophie des paradigmes de Rust et adapter ses réflexes en ce sens. A contrario, je me souviens au début m'être exercé à simuler des classes d'objets au sens 'classique' en utilisant les mécanismes de traits, de mod et de généricité (histoire de me prouver que rust avait l'expressivité suffisante pour programmer objet de la manière que je l'avais appris...). J'y suis arrivé, mais c'était très lourd!

    La programmation des macros (procédurales ou non) n'est pas particulièrement légère non plus, de mon point de vue.

    Mais il ne s'agit pas là de cas d'usage usuels.

  20. #40
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 562
    Points : 15 493
    Points
    15 493
    Par défaut
    Citation Envoyé par Steinvikel Voir le message
    La comparaison de Rust face à C++ m'a toujours paru assez fallacieuse :
    Je la vois toujours évoqué sans tenir compte de l'écosystème du développeur, à croire que ces 2 langages sont comparés nus.
    Les deux comparaisons peuvent avoir un sens, il s'agit juste de savoir de quoi on parle.
    Bien sur qu'un langage comme Rust n'a pas encore tout l'écosystème de bibliothèques et d'outils qui ont été développé pour C++ pendant plusieurs dizaines d'années, ceci dit c'est un problème qui a déjà bien commencé à se résorber. Si on veut un langage a utiliser immédiatement, c'est bien évidement à prendre en compte au moment du choix.

    Ca ne veut pas dire pour autant qu'il n'y a pas d’intérêt à analyser les capacités intrinsèques d'un langage pour savoir ce qu'il permet déjà de faire techniquement, même si les bibliothèques restent a coder, et ce qu'il ne permettra pas de faire, peu importe ce que l'on code.

    Citation Envoyé par Steinvikel Voir le message
    Comparer un langage qui tire parti d'un complément de fonctionnalités par des outils externes, à un autre qui en incorpore certaines en natif, mais le faire sans ces dit outils a-t-il du sens ?
    Il faudrait préciser ce que tu entends par là car Rust comme C++ sont relativement indépendant d'outils externes, pour le fonctionnement de base des langages au moins.

    Citation Envoyé par Steinvikel Voir le message
    Dans un second temps, Bjarne Stroustrup rappelait à l'occasion de la cppCon 2023 (billet dvp.com du 6 octobre ici) que la question de la sécurité (et la sûreté) n'a pas démarré il y a quelques années, et que les principales règles de codage qui gouverne la sécurité par le code existent depuis au minimum les années 90.
    Depuis cette époque la problématique n'a pas changé --> le difficulté n°1 est de trouver une solution pour que la masse des développeurs aient connaissance de ces règles, la difficulté n°2, qu'ils finissent par avoir l'habitude de les appliquer.
    La difficulté n°2 vient du fait que l'on code avant tout pour répondre à un besoin pratique, et que parmi tous les aspects à traiter sur les concepts à choisir et leur implémentation, les développeurs finissent par oublier d'appliquer certaines notions de sécurité.
    Si c'est vrai que comme le dit Stroustrup dans sa conférence, la sécurité du C++ a évolué tout au long de son histoire, ça a quand même été, pendant très longtemps, une préoccupation secondaire bien derrière la performance et la compatibilité. Il y avait certes de bonnes raisons de faire ce choix, mais, l'état actuel du C++ au niveau de la sécurité en est clairement la conséquence. Bjarne Stroustrup ne se penche sérieusement sur la sécurité du C++ que depuis qu'il y est poussé par l'arrivée des langages de bas niveau alternatifs et par les autorités de sureté.

    Là ou il me parait très lucide dans sa conférence, c'est quand il dit clairement : "Being careful does not scale" (Être prudent n'est pas tenable à grande échelle). Ca change des discours qu'on peut entendre encore bien trop souvent sur le C et le C++. Par contre, une bonne partie de son discours ressemble pas mal à du déni des problèmes. En même temps c'est dur de lui reprocher de défendre son bébé. Quand il dit qu'il n'y a pas que la sécurité mémoire à prendre en compte, c'est vrai, mais c'est quand même de l'ordre des 2/3 des vulnérabilités critiques dans la plupart des grosse bases de code C++, y compris celles moderne et surveillées. Et pour les autres type de problème de sécurité qu'il évoque, le C++ est là encore à la traine comparé a ses alternatives modernes.

    Citation Envoyé par Steinvikel Voir le message
    Mais je constate aussi que beaucoup de code produit sont lourd à l'exécution (mémoire, CPU...) parce que le code n'est pas suffisamment verbeux (explicitement écrit).
    Un exemple flagrant, lors d'une démonstration par Jason Turner à la cppCon 2016, où après avoir fait un mapping des couleurs, il faisait face à un overhead.
    C'est le coté potentiellement surprenant des optimisations, mais pour le coup ce genre de chose peut tout aussi bien arriver en C++ qu'en Rust

Discussions similaires

  1. Parts de marchés des langages de programmation
    Par Marc Lussac dans le forum Langages de programmation
    Réponses: 51
    Dernier message: 21/05/2013, 13h51
  2. Index TIOBE du classement des langages de programmation
    Par Gordon Fowler dans le forum Actualités
    Réponses: 564
    Dernier message: 13/01/2013, 18h51
  3. Passer des paramètres à un programme
    Par Cravis dans le forum VB 6 et antérieur
    Réponses: 4
    Dernier message: 08/11/2007, 14h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 02/04/2006, 23h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo