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

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    9 768
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 9 768
    Par défaut La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust
    La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire,
    pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

    La National Security Agency (NSA) a publié des conseils pour aider les développeurs et les opérateurs de logiciels à prévenir et à atténuer les problèmes de sécurité de la mémoire logicielle, qui représentent une grande partie des vulnérabilités exploitables. La fiche d'information sur la cybersécurité « Sécurité de la mémoire logicielle » souligne comment les cyberacteurs malveillants peuvent exploiter les problèmes de mauvaise gestion de la mémoire pour accéder à des informations sensibles, promulguer l'exécution de code non autorisé et causer d'autres impacts négatifs.

    « Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui », a déclaré Neal Ziring, directeur technique de la cybersécurité. « Nous devons utiliser systématiquement des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants ».


    La société moderne s'appuie fortement sur l'automatisation basée sur les logiciels, faisant implicitement confiance aux développeurs pour écrire des logiciels qui fonctionnent de la manière attendue et ne peuvent pas être compromis à des fins malveillantes. Alors que les développeurs effectuent souvent des tests rigoureux pour préparer la logique des logiciels à des conditions surprenantes, les vulnérabilités logicielles exploitables sont encore souvent basées sur des problèmes de mémoire. Les exemples incluent le débordement d'une mémoire tampon et l'exploitation des problèmes liés à la façon dont le logiciel alloue et désalloue la mémoire.

    Microsoft a révélé lors d'une conférence en 2019 que, de 2006 à 2018, 70 % de leurs vulnérabilités étaient dues à des problèmes de sécurité de la mémoire. Google a également trouvé un pourcentage similaire de vulnérabilités de sécurité de la mémoire sur plusieurs années dans Chrome. Les cyber-acteurs malveillants peuvent exploiter ces vulnérabilités pour l'exécution de code à distance ou d'autres effets indésirables, qui peuvent souvent compromettre un appareil et être la première étape des intrusions réseau à grande échelle. Les langages couramment utilisés, tels que C et C++, offrent une grande liberté et une grande flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le développeur pour effectuer les vérifications nécessaires sur les références mémoire.

    De simples erreurs peuvent conduire à des vulnérabilités exploitables basées sur la mémoire. Les outils d'analyse logicielle peuvent détecter de nombreux cas de problèmes de gestion de la mémoire et les options d'environnement d'exploitation peuvent également fournir une certaine protection, mais les protections inhérentes offertes par les langages logiciels sécurisés pour la mémoire peuvent prévenir ou atténuer la plupart des problèmes de gestion de la mémoire.

    La NSA recommande d'utiliser un langage sécurisé pour la mémoire lorsque cela est possible. Bien que l'utilisation de protections supplémentaires pour les langages non sécurisés pour la mémoire et l'utilisation de langages sécurisés pour la mémoire n'offrent pas une protection absolue contre les problèmes de mémoire exploitables, elles offrent une protection considérable.

    Par conséquent, la communauté logicielle globale du secteur privé, du milieu universitaire et du gouvernement américain a lancé des initiatives visant à orienter la culture du développement logiciel vers l'utilisation de langages sécurisés dans la gestion de la mémoire.

    Nom : nsa.png
Affichages : 28514
Taille : 544,8 Ko

    Le problème de la sécurité de la mémoire

    La façon dont un programme logiciel gère la mémoire est essentielle pour prévenir de nombreuses vulnérabilités et garantir la robustesse d'un programme. L'exploitation d'une gestion de la mémoire médiocre ou négligente peut permettre à un cyberacteur malveillant d'accomplir des actes néfastes, tels que planter le programme à volonté ou modifier les instructions du programme en cours d'exécution pour faire ce que l'acteur désire. Même des problèmes inexploitables avec la gestion de la mémoire peuvent entraîner des résultats de programme incorrects, une dégradation des performances du programme au fil du temps ou des plantages de programme apparemment aléatoires.

    La sécurité de la mémoire est une vaste catégorie de problèmes liés à la façon dont un programme gère la mémoire. Un problème courant est appelé « débordement de tampon », où les données sont accessibles en dehors des limites d'un tableau. D'autres problèmes courants concernent l'allocation de mémoire. Les langages peuvent allouer de nouveaux emplacements de mémoire pendant l'exécution d'un programme, puis désallouer la mémoire, également appelée libération ou libération de la mémoire, plus tard lorsque la mémoire n'est plus nécessaire. Mais si cela n'est pas fait avec soin par le développeur, de la nouvelle mémoire peut être allouée encore et encore au fur et à mesure que le programme s'exécute. Par conséquent, la mémoire n'est pas toujours libérée lorsqu'elle n'est plus nécessaire, ce qui entraîne une fuite de mémoire qui pourrait entraîner le programme à manquer de mémoire disponible.

    En raison d'erreurs logiques, les programmes peuvent également tenter d'utiliser la mémoire qui a été libérée, ou même de libérer de la mémoire qui a déjà été libérée. Un autre problème peut survenir lorsque les langages autorisent l'utilisation d'une variable qui n'a pas été initialisée, ce qui fait que la variable utilise la valeur précédemment définie à cet emplacement en mémoire. Enfin, un autre problème difficile est appelé une condition de concurrence. Ce problème peut se produire lorsque les résultats d'un programme dépendent de l'ordre de fonctionnement de deux parties du programme accédant aux mêmes données. Tous ces problèmes de mémoire sont des occurrences beaucoup trop courantes.

    En exploitant ces types de problèmes de mémoire, les acteurs malveillants, qui ne sont pas liés par les attentes normales d'utilisation du logiciel, peuvent découvrir qu'ils peuvent entrer des entrées inhabituelles dans le programme, provoquant l'accès, l'écriture, l'allocation ou la désallocation de la mémoire de manière inattendue. Dans certains cas, un acteur malveillant peut exploiter ces erreurs de gestion de la mémoire pour accéder à des informations sensibles, exécuter du code non autorisé ou provoquer d'autres impacts négatifs. Puisqu'il peut falloir beaucoup d'expérimentation avec des entrées inhabituelles pour en trouver une qui provoque une réponse inattendue, les acteurs peuvent utiliser une technique appelée "fuzzing" pour créer de manière aléatoire ou intelligente une multitude de valeurs d'entrée dans le programme jusqu'à ce qu'on en trouve une qui provoque le plantage du programme.

    Les progrès des outils et des techniques de fuzzing ont facilité la recherche d'entrées problématiques pour les acteurs malveillants ces dernières années. Une fois qu'un acteur découvre qu'il peut faire planter le programme avec une entrée particulière, il examine le code et travaille pour déterminer ce qu'une entrée spécialement conçue pourrait faire. Dans le pire des cas, une telle entrée pourrait permettre à l'acteur de prendre le contrôle du système sur lequel le programme s'exécute.

    Nom : national.png
Affichages : 6409
Taille : 94,2 Ko

    Langages sécurisés dans la gestion de la mémoire

    L'utilisation d'un langage sécurisé pour la mémoire peut aider à empêcher les programmeurs d'introduire certains types de problèmes liés à la mémoire. La mémoire est gérée automatiquement dans le cadre du langage informatique ; il ne repose pas sur l'ajout de code par le programmeur pour implémenter des protections de mémoire. Le langage institue des protections automatiques en utilisant une combinaison de vérifications au moment de la compilation et de l'exécution. Ces fonctionnalités inhérentes au langage protègent le programmeur contre l'introduction involontaire d'erreurs de gestion de la mémoire. C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

    Même avec un langage sécurisé pour la mémoire, la gestion de la mémoire n'est pas entièrement sécurisée pour la mémoire. La plupart des langages de mémoire sécurisés reconnaissent que les logiciels doivent parfois exécuter une fonction de gestion de mémoire non sécurisée pour accomplir certaines tâches. En conséquence, des classes ou des fonctions sont disponibles qui sont reconnues comme non sécurisées pour la mémoire et permettent au développeur d'effectuer une tâche de gestion de la mémoire potentiellement dangereuse. Certains langages exigent que tout ce qui n'est pas sûr en mémoire soit explicitement annoté comme tel pour que le développeur et tous les réviseurs du programme sachent qu'il n'est pas sûr. Les langages sécurisés pour la mémoire peuvent également utiliser des bibliothèques écrites dans des langages non sécurisés pour la mémoire et peuvent donc contenir des fonctionnalités de mémoire non sécurisées. Bien que ces façons d'inclure la mémoire ne soient pas sûres et subvertissent la sécurité inhérente à la mémoire, elles aident à localiser où des problèmes de mémoire pourraient exister, permettant un examen plus approfondi de ces sections de code.

    Les langages varient dans leur degré de sécurité de la mémoire institué par des protections et des atténuations inhérentes. Certains langages n'offrent qu'une sécurité de mémoire relativement minimale alors que certains langages sont très stricts et offrent des protections considérables en contrôlant la manière dont la mémoire est allouée, accessible et gérée. Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour obtenir simplement le programme à compiler en raison des vérifications et des protections.

    La sécurité de la mémoire peut être coûteuse en matière de performances et de flexibilité. La plupart des langages mémoire sécurisés nécessitent une sorte de récupération de place pour récupérer la mémoire qui a été allouée, mais qui n'est plus nécessaire au programme. Il existe également une surcharge de performances considérable associée à la vérification des limites de chaque accès à la baie qui pourrait potentiellement se trouver en dehors de la baie.

    Alternativement, un impact similaire sur les performances peut exister dans un langage non sécurisé en mémoire en raison des vérifications qu'un développeur ajoute au programme pour effectuer la vérification des limites et d'autres protections de gestion de la mémoire. Les coûts supplémentaires liés à l'utilisation de langages non sécurisés pour la mémoire incluent une corruption de mémoire difficile à diagnostiquer et des plantages occasionnels des programmes ainsi que de potentielles exploitations des vulnérabilités d'accès à la mémoire. Il n'est pas anodin de faire passer une infrastructure de développement logiciel mature d'un langage informatique à un autre. Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage.

    Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera.

    Source : NSA

    Et vous ?

    Que pensez-vous des conseils de la NSA ? Y en a-t-il que vous appliquez déjà ?
    Que pensez-vous du fait que l'agence préconise l'utilisation des langages de programmation sécurisés pour la mémoire comme C#, Go, Java, Ruby, Rust et Swift ?
    « Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage. Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera ». Qu'en pensez-vous ? Êtes-vous d'accord avec l'agence ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre Expert Avatar de KiLVaiDeN
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    2 890
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 2 890
    Par défaut
    Utiliser un container ou une sandbox peut aussi permettre d'isoler un programme de son environnement, ce qui me semble être une bonne solution pour éviter les "débordements".

    Je suis étonné que dans la liste des langages de programmation "sécurisés dans l'utilisation de la mémoire" Python et Javascript(Typescript) ne soient pas mentionnés, alors qu'ils sont largement utilisés et "memory-safe" me semble-t-il. PHP aussi, de part sa nature interprétée pourrait faire partie de cette liste. Ou Perl. Les exemples sont nombreux.

  3. #3
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    556
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 556
    Par défaut
    Citation Envoyé par KiLVaiDeN Voir le message
    Je suis étonné que dans la liste des langages de programmation "sécurisés dans l'utilisation de la mémoire" Python et Javascript(Typescript) ne soient pas mentionnés, alors qu'ils sont largement utilisés et "memory-safe" me semble-t-il. PHP aussi, de part sa nature interprétée pourrait faire partie de cette liste. Ou Perl. Les exemples sont nombreux.
    Il n’y a pas de quoi l’être, ce ne sont que des exemples illustratifs qui n’ont pas vocation à être exhaustifs. On pourrait aussi ajouter Ruby (utilisé pour développer GitLab), erlang, et plein plein d’autres !

    Il est écrit : C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

    Perl a une mention particulière en terme de sécurité : ses variables teintées (mais on s’écarte du sujet).

  4. #4
    Membre averti
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2015
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Août 2015
    Messages : 16
    Par défaut
    Utiliser un container ou une sandbox peut aussi permettre d'isoler un programme de son environnement, ce qui me semble être une bonne solution pour éviter les "débordements".
    C'est une barrière de sécurité supplémentaire, mais certainement pas une solution.

    Python et php ne sont pas exempts de bufferoverflow non plus.
    Et a vrai dire, du C++ moderne est aussi plutôt bien calé sur le "memory safety", par contre il continue a autoriser des constructions bien barbares complètements unsafe.
    Entre le legacy et les codeurs mal formés (faudrait déjà des formateurs bien formés...), on comprend l'intérêt de language "paranoïdes" tel que Rust.

  5. #5
    Membre très actif Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 220
    Par défaut
    faire confiance a la NSA... Sécuriser=>bien contrôler. De la part d'une organisation qui espionne le monde entier

  6. #6
    Membre averti
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2015
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Août 2015
    Messages : 16
    Par défaut
    Citation Envoyé par vivid Voir le message
    faire confiance a la NSA... Sécuriser=>bien contrôler. De la part d'une organisation qui espionne le monde entier
    Bein ils s'y connaissent pour le coup. J'utilise Ghidra (un outil créé par la NSA) assez régulièrement.
    Bon, y'avait une petite backdoor qui trainait mais elle a été fixée.

  7. #7
    Membre actif
    Homme Profil pro
    Retraité
    Inscrit en
    Février 2009
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Retraité
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2009
    Messages : 22
    Par défaut C'est pas nouveau
    Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java

  8. #8
    Membre très actif Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 220
    Par défaut
    "Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java "

    un bon nivellement par le bas, bravo

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vivid Voir le message
    "Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java "

    un bon nivellement par le bas, bravo
    Le nivellement par le bas c'est de rester sur des vieux langages et ne pas évoluer.

  10. #10
    Membre très actif Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 220
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Le nivellement par le bas c'est de rester sur des vieux langages et ne pas évoluer.
    Ce serait un commercial qui me disait çà..., ce sont dans les vieux pots que l'on fait les meilleures soupes.

    Dans les écoles de cuisine une nouvelle spécialité (véridique); décongeler les plats préparés !



  11. #11
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par vivid Voir le message
    Ce serait un commercial qui me disait çà..., ce sont dans les vieux pots que l'on fait les meilleures soupes.

    Dans les écoles de cuisine une nouvelle spécialité (véridique); décongeler les plats préparés !


    Perdre son temps à gérer de la mémoire plutôt que coder j'appelle ça une perte de temps.

  12. #12
    Membre très actif Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    220
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 220
    Par défaut
    Citation Envoyé par Erviewthink Voir le message
    Perdre son temps à gérer de la mémoire plutôt que coder j'appelle ça une perte de temps.
    faut poursuivre dans cette philosophie !! un seul type de variable etc etc... on est plus niveau ingénieur, mais conducteur de ligne automatisé.

  13. #13
    Membre actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mai 2013
    Messages
    35
    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 : 35
    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

  14. #14
    Membre Expert
    Avatar de Pyramidev
    Homme Profil pro
    Tech Lead
    Inscrit en
    Avril 2016
    Messages
    1 515
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Tech Lead

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 515
    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.

  15. #15
    Membre très actif
    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
    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..

  16. #16
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 326
    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 326
    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

  17. #17
    Membre actif
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Mai 2013
    Messages
    35
    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 : 35
    Par défaut
    Certes mais ça reste mon scalpel préféré pour faire du code 😊

  18. #18
    Membre éclairé
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    952
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 952
    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)

  19. #19
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 746
    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 746
    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.

  20. #20
    Membre actif
    Profil pro
    Inscrit en
    Août 2006
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : France

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

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, 14h51
  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, 19h51
  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, 15h32
  4. L'avenir des langages de programmation
    Par LordBob dans le forum Langages de programmation
    Réponses: 14
    Dernier message: 03/04/2006, 00h03

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