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

C Discussion :

C-rusted : les avantages de Rust, en C sans les inconvénients,


Sujet :

C

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mai 2019
    Messages
    1 903
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2019
    Messages : 1 903
    Points : 37 203
    Points
    37 203
    Par défaut C-rusted : les avantages de Rust, en C sans les inconvénients,
    C-rusted : les avantages de Rust, en C sans les inconvénients,
    une analyse des trois chercheurs de l’Université de Parme en Italie

    Le langage de programmation Rust est un projet ambitieux de la Fondation Mozilla - un langage qui prétend être la prochaine étape de l'évolution du C et du C++. Au fil des années d'existence de ces langages, certains de leurs défauts fondamentaux n'ont toujours pas été corrigés, comme les erreurs de segmentation, le contrôle manuel de la mémoire, les risques de fuites de mémoire et le comportement imprévisible du compilateur. Rust a été créé pour résoudre ces problèmes tout en améliorant la sécurité et les performances.

    Roberto Bagnara, Abraham Bagnara et Federico Serafini trois chercheurs de l’Université de Parme en Italie ont produit un essai dans lequel les chercheurs présentent les avantages de Rust, en C.


    Notons que Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités indispensables du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

    Nom : cB.png
Affichages : 168761
Taille : 43,7 Ko

    Avec Rust, il est possible de développer des pilotes de périphériques, des systèmes embarqués, des systèmes d'exploitation, des jeux, des applications web, et bien d'autres choses encore. Des centaines d'entreprises dans le monde entier utilisent Rust en production pour des solutions multiplateformes et économes en ressources. Des logiciels connus et appréciés, comme Firefox, Dropbox, et Cloudflare, utilisent ce langage. De la startup à la multinationale, du système embarqué au service web à haute disponibilité, Rust serait une excellente solution.

    Le langage C est un langage de programmation qui appartient au paradigme de programmation impérative. Inventé au début des 1970 dans les Laboratoires Bell pour aider la programmation du système Unix, C est devenu un des langages les plus utilisés. Il n’est pas consacré qu’à la programmation système. C’est un langage compilé, typé avec des instructions bas-niveau. Voici, ci-dessous, un exemple de programme :

    Code : 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
     
    #include  
    #include  
     
    int somme(int); 
     
    int 
    main(int argc, char **arg){ 
        int i = 10; 
        printf("La somme des %d entiers est %d \n", i, somme(i)); 
    return EXIT_SUCCESS ; 
    }
     
    int 
    somme(int i){ 
        int resultat = 0; 
        for (int k = 0; k <= i; k++) 
           resultat += k; 
       return resultat; 
    }

    Selon les chercheurs, l’effervescence actuelle autour de Rust révèle que l'industrie est prête à accepter que les programmeurs prennent une approche plus disciplinée en adoptant un typage de données fort renforcé par des annotations de programme. C'est le véritable changement de perspective : la technologie pour assister cette nouvelle attitude dans la création de code C avec des garanties d'intégrité sans précédent est disponible, dans son essence, depuis des décennies.

    DE C À C-RUSTED

    Même si le langage de programmation C est (pour des raisons d'efficacité uniquement) statiquement typé, les types ne définissent que la représentation interne des données et rien de plus : les types en C n'offrent pas aux programmeurs un moyen d'exprimer les propriétés non triviales des données qui sont liées à la logique du programme. Par exemple :

    • un fichier ouvert a le même type qu'un fichier fermé ;
    • une ressource ou une transaction a le même type indépendamment de son état ;
    • une référence exclusive et une référence partagée à une ressource sont indiscernables ;
    • un nombre entier avec des valeurs spéciales qui représentent des conditions d'erreur est indiscernable d'un nombre entier ordinaire.

    En C-rusted, toutes ces différences peuvent être exprimées de manière incrémentielle, ce qui permet d'améliorer la documentation, la lisibilité et la réutilisation du code. Plus important encore, cela permet à C-rusted Analyzer, qui est basé sur la plateforme de vérification logicielle, de vérifier l'exactitude avec n'importe quelle architecture, et pour chaque compilateur.

    Pour illustrer, les chercheurs présentent le programme ci-dessous, que le compilateur GNU C compile sans aucun avertissement, même avec un niveau d'avertissement très élevé. Le programme contient beaucoup d'erreurs, y compris l'incrément numérique sans signification.

    Code : 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
    #include 
    #include 
    #include 
    #define BUFSIZE (100U) 
    extern void process(char *string); 
    int main(int argc, const char *argv[]) { 
    if (argc != 2)
       return 1; 
    int fd = open(argv[1], O_RDONLY); 
    char *buf = (char *) malloc(BUFSIZE); 
    ++fd; 
    ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
    buf[bytes] = '\0'; 
    process(buf); 
    return 0;
    }

    Un programme C compilant sans avertissement avec gcc -c -std=c18 -Wall -Wextra -Wpedantic

    Lorsqu'il est soumis à l'analyseur C-rusted, le même programme déclenche plusieurs diagnostics, résumés dans le tableau ci-dessous où la notation wn sur un point du programme signifie que l'avertissement indiqué est donné à ce point du programme.

    Code : 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
    #include 
    #include 
    #include
     #define BUFSIZE (100U) 
    extern void process(char *string); 
    int main(int argc, const char *argv[]) { 
        if (argc != 2) 
            return 1; 
       int fd = open(argv[1], O_RDONLY); 
       char *buf = (char *) malloc(BUFSIZE); 
      ++fdw1; 
    ssize_t bytes = read(fdw2, bufw3 , BUFSIZE - 1U); 
    buf[bytes] w4w5 = '\0'; 
    process(bufw6);
    returnw7w8 0; 
    }

    w1 : Après avoir reçu la valeur de retour de open(), fd contient un descripteur de fichier ou la valeur erronée -1 : fd ne peut pas être incrémenté ;
    w2, w3, w4, w5 : fd n'est pas un descripteur de fichier valide, bytes peut être -1, buf peut être NULL ;
    w6 : Est-ce que process() prend la propriété, c'est à dire peut/doit-il désallouer son argument ?
    w7 : Le descripteur de fichier contenu dans fd est certainement fui ici ;
    w8 : La mémoire pointée par buf est possiblement divulguée ici ;

    L'analyseur C-rusted donne plusieurs avertissements sur le même programme C

    Une version beaucoup plus saine du programme est illustrée ci-dessous :
    Code : 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
    #include 
    #include 
    #include 
    // Include C-rusted declarations, e.g., for e_hown. 
    #include 
    #define BUFSIZE (100U) 
    // The actual parameter must be a valid (hence, non-null) pointer to a char array 
    // in the heap of which process() will take ownership, which implies the caller 
    // must have ownership for otherwise it would be unable to pass it on. 
    extern void process(char * e_hown string); 
    int main(int argc, const char *argv[]) { 
         if (argc != 2) 
              return 1; 
         int fd; // `fd` value is indeterminate. 
         fd = open(argv[1], O_RDONLY); 
         // `fd` value is either the erroneous value -1 or an open file descriptor. 
         if (fd == -1) 
              return 1; 
         // `fd` value is definitely an open file descriptor. 
         char *buf = (char *) malloc(BUFSIZE); 
         // `buf` value is either null or points to a heap-allocated char array. 
         if (buf == NULL) 
              return 1; 
         // `buf` value definitely points to a heap-allocated char array. 
         ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
         // `bytes` value is either the erroneous value -1 or the number of bytes 
        // read into `buf`. if (bytes == -1) 
               return 1; 
       // `bytes` value is definitely the number of bytes read into `buf`. 
       buf[bytes] = '\0'; 
      // process() takes ownership of `buf` and will deallocate it: no memory leak. 
     process(buf); 
     // close() properly closes the file descriptor contained into `fd`: 
     // no file descriptor leak. 
     close(fd); 
    // `fd` value is an ordinary integer and cannot be used as a file descriptor 
    // (it can be overwritten of course). 
    // ... 
    return 0; 
    }
    Le C-rusted Analyzer ne donne aucun avertissement sur ce program

    Elle montre clairement que, bien que le type (statique) de fd soit int, pendant toute sa durée de vie, la valeur de fd a des propriétés qui changent tout au long du corps de la fonction ; de même pour buf et les bytes. En d'autres termes, le système de types C est capable de suivre les propriétés dynamiques des objets.

    Selon les chercheurs, C-rusted est une solution pragmatique et rentable pour élever le jeu de la programmation C à des garanties d'intégrité sans précédent, sans renoncer à ce que l'écosystème C offre aujourd'hui. « C'est-à-dire continuer à utiliser le C, exactement comme avant, en utilisant les mêmes compilateurs et les mêmes outils, le même personnel, mais en ajoutant progressivement au programme les informations requises pour démontrer la correction, en utilisant un système d'annotations qui n'est pas basé sur la logique mathématique et qui peut être enseigné aux programmeurs en une semaine de formation. »

    Ce n'est que lorsque l'ajout d'annotations montre la présence d'un problème qu'une modification du code sera nécessaire afin de corriger le bug latent qui est alors visible : dans tous les autres cas, le comportement du code restera exactement le même. Cette technique n'est pas nouvelle : elle s'appelle le typage progressif et consiste à ajouter des informations qui ne sont pas nécessaires à la compréhension du code, mais qui permettent de vérifier son exactitude.

    Source : Roberto Bagnara, Abraham Bagnara et Federico Serafini, chercheurs de l’Université de Parme

    Et vous ?

    Quel est votre avis sur le sujet ?

    Voir aussi :

    Rust 1.65 est disponible, elle apporte les types génériques associés stables, ils permettent d'avoir des génériques (type, lifetime, ou const) sur les types associés

    La prise en charge de Rust pour le développement du noyau Linux fait l'objet d'une nouvelle série de discussions, après une proposition de RFC
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 717
    Points : 31 028
    Points
    31 028
    Billets dans le blog
    1
    Par défaut
    Bonjour
    Citation Envoyé par Bruno Voir le message
    Pour illustrer, les chercheurs présentent le programme ci-dessous, que le compilateur GNU C compile sans aucun avertissement, même avec un niveau d'avertissement très élevé. Le programme contient beaucoup d'erreurs, y compris l'incrément numérique sans signification.

    Code : 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
    #include 
    #include 
    #include 
    #define BUFSIZE (100U) 
    extern void process(char *string); 
    int main(int argc, const char *argv[]) { 
    if (argc != 2)
       return 1; 
    int fd = open(argv[1], O_RDONLY); 
    char *buf = (char *) malloc(BUFSIZE); 
    ++fd; 
    ssize_t bytes = read(fd, buf, BUFSIZE - 1U); 
    buf[bytes] = '\0'; 
    process(buf); 
    return 0;
    }
    "Sans erreur ou avertissement"... Testons donc cela...
    Voici le résultat de la compilation telle que mentionnée (gcc -c -std=c18 -Wall -Wextra -Wpedantic) du code cité en référence (compilateur gcc 11.3.0 sur une Ubuntu 22.04 LTS)...
    Code : 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
    x.c:1:10: error: #include expects "FILENAME" or <FILENAME>
        1 | #include
          |          ^
    x.c:2:10: error: #include expects "FILENAME" or <FILENAME>
        2 | #include
          |          ^
    x.c:3:10: error: #include expects "FILENAME" or <FILENAME>
        3 | #include
          |          ^
    x.c: In function ‘main’:
    x.c:9:10: warning: implicit declaration of function ‘open’ [-Wimplicit-function-declaration]
        9 | int fd = open(argv[1], O_RDONLY);
          |          ^~~~
    x.c:9:24: error: ‘O_RDONLY’ undeclared (first use in this function)
        9 | int fd = open(argv[1], O_RDONLY);
          |                        ^~~~~~~~
    x.c:9:24: note: each undeclared identifier is reported only once for each function it appears in
    x.c:10:22: warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
       10 | char *buf = (char *) malloc(BUFSIZE);
          |                      ^~~~~~
    x.c:1:1: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
      +++ |+#include <stdlib.h>
        1 | #include
    x.c:10:22: warning: incompatible implicit declaration of built-in function ‘malloc’ [-Wbuiltin-declaration-mismatch]
       10 | char *buf = (char *) malloc(BUFSIZE);
          |                      ^~~~~~
    x.c:10:22: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
    x.c:12:1: error: unknown type name ‘ssize_t’
       12 | ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
          | ^~~~~~~
    x.c:12:17: warning: implicit declaration of function ‘read’ [-Wimplicit-function-declaration]
       12 | ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
          |                 ^~~~
    Donc "sans erreur ou avertissement" faut le dire vite quoi parce que de mon côté j'ai eu l'impression que le compilo m'aurait craché à la figure s'il l'avait pu...

    Citation Envoyé par Bruno Voir le message
    Quel est votre avis sur le sujet ?
    Ben déjà donc à partir du moment où on exagère les défauts d'un trucX c'est assez facile de promouvoir le trucY. Mais aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers. (Herbert Mayer).

    Mon prof de piano avec qui on discute et où on parlait des artistes en général (ceux qui accompagnent les chanteurs) m'a dit justement hier que ce ne sont pas les chanteurs qui choisissent leurs musiciens mais les autres musiciens. Et tout se fait au bouche à oreille. Si un type commence à fréquenter les milieux en se disant musicien il finira par être appelé. Mais c'est sur la scène qu'il devra prouver sa valeur. S'il joue bien on ne lui dira rien mais il sera redemandé. Et s'il ne joue pas bien, on ne lui dira rien non plus mais il ne sera plus rappelé. Je pense que c'est un peu pareil avec les langages de prog. Peut-être que le Rust est un super langage (je ne le connais que très peu donc je n'ai aucune raison de le critiquer) mais ce n'est pas en disant "ouais regardez le C ceci, le C cela" qu'il percera. C'est en faisant ses propres preuves. On ne s'élève jamais en enfonçant les autres...

    [edit]
    Pardon pardon, il y a une erreur dans la retranscription du code qu'a fait Bruno (hier quand j'ai testé je n'étais pas allé voir le PDF).
    Le code exact de l'article commence par ces 3 lignes
    Code c : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    #include <unistd.h>
    #include <stdlib.h>
    #include <fcntl.h>
    Le code recopié ici ne montre pas les include complets. Et si on corrige alors effectivement le compilateur digère le tout sans broncher.

    Mais cela ne change rien au reste de ce que je pense. Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait". Donc si le programmeur fait n'importe quoi tout en restant syntaxiquement correct il n'y a aucune raison que le compilateur râle. Ce n'est donc pas la peine de venir ensuite le montrer du doigt en disant "oh regardez le compilateur n'a rien dit" car je le répète, cela était le prédicat initial et assumé de ce langage qui a, rappelons le, été créé en 1968 à l'époque où les ordinateurs n'avaient que 4Ko de RAM et qui donc peut difficilement rivaliser avec un langage du XXI° siècle. Sauf qu'en réalité il n'en a pas besoin, lui il a fait ses preuves.
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 125
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 125
    Points : 33 028
    Points
    33 028
    Billets dans le blog
    4
    Par défaut
    Je suppose que le forcing de Rust est sensé attirer les gens à s'y intéresser. Perso ça a fini par me faire tout l'inverse
    Rust peut tout faire, et est utilisé par des centaines d'entreprises. Woohoo ce nombre est énorme. Je pense qu'il va falloir forcer encore un peu pour percer ?
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    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
    La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire, et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

    Je sais pas peut-etre c'est une erreur, mais un "analyseur" supposé rendre le code C plus robuste qui rate ça je m'en passe volontier. Et c'est fatiguant d'entendre tout le monde essayer de rendre les autres langages similaire a Rust ou clamer que c'est possible.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 643
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 643
    Points : 10 597
    Points
    10 597
    Par défaut
    Citation Envoyé par thamn Voir le message
    La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire,
    le commentaire dit que c'est la fonction process qui devient propriétaire et libère le buffer : "process() takes ownership of `buf` and will deallocate it: no memory leak."

    Citation Envoyé par thamn Voir le message
    et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.
    je dirais que le pire c'est de faire l'allocation avant l'ouverture. Il y a + de chances que l'ouverture échoue que l'allocation.

    Les exemples, pour moi, sont pertinents dans 1 sens : 1 développeur qui connait le C mais ne connait pas/ peu le C "industriel" (les normes, les règles de codage, le C défensif, …), tu le mets derrière cet analyseur C-rusted et son code devient presque opérationnel.
    Le code "sain" ici c'est du "C défensif" du style :
    Code : 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
    #include <stdlib.h>
     
    #include <fcntl.h>
    #include <sys/types.h>
    #include <unistd.h>
     
     
    #define BUFSIZE (100U)
    extern void process(char* string);
     
     
    int main(int argc, const char *argv[])
    {
        int ret;
     
        if (argc == 2) {
            int fd = open(argv[1], O_RDONLY);
     
            if (fd != -1) {
                char* buf = malloc(BUFSIZE);
     
                if (buf != NULL) {
                    ssize_t bytes = read(fd, buf, BUFSIZE - 1U);
     
                    if (bytes != -1) {
                        buf[bytes] = '\0';
                        process(buf); // without free
     
                        ret = EXIT_SUCCESS;
                    } else {
                        ret = 1; // error - read
                    }
     
                    free(buf);
                } else {
                    ret = 1; // error - allocation
                }
     
                close(fd);
            } else{
                ret = 1; // error - open
            }
        } else {
            ret = 1; // error - arg
        }
     
     
        return ret;
    }
    Édit : @Sve@r a trouvé 1 coquille : (que j'ai corrigé)

  6. #6
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 311
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 311
    Points : 4 220
    Points
    4 220
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Je suppose que le forcing de Rust est sensé attirer les gens à s'y intéresser. Perso ça a fini par me faire tout l'inverse
    Je n'ai pas l'impression que ça soit la fondation Mozilla qui mettent en avant RUST plus que nécessaire. Je ressens plus une volonté d'un certain nombre d'entreprises et ici d'université de mettre en avant ce langage au détriment des autres.

    J'ai adopté RUST mais je ne vais pas forcer les autres à l'utiliser ni dénigrer le C et le C++.
    Ma pensée sur le C et le C++ est qu'ils ont fait leurs preuves, on ne va pas réécrire tout le code existant, qu'ils ont des défauts qui peuvent être corrigés en RUST. Je soutiens toutefois la question à se poser d'utiliser RUST quand on initie de nouveaux projets.

  7. #7
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 717
    Points : 31 028
    Points
    31 028
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par foetus Voir le message
    Le code "sain" ici c'est du "C défensif" du style...
    Attention, je pense que tu as écrit une coquille en continuant le travail dans la partie if (bytes == -1). Pour moi faut inverser le test
    Ou alors c'est que tu veux faire du "défensif++"...
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  8. #8
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    397
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 397
    Points : 698
    Points
    698
    Par défaut
    Citation Envoyé par thamn Voir le message
    le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.
    A partir du moment ou process prend un pointeur et prend l'ownership, pas d'autre choix que de faire une allocation dynamique.

    Par contre, on peut critiquer le choix de design de celui qui a fait process comme ca et oblige a faire de l'allocation dynamique.

    Citation Envoyé par foetus Voir le message
    le commentaire dit que c'est la fonction process qui devient propriétaire et libère le buffer : "process() takes ownership of `buf` and will deallocate it: no memory leak."
    Il y a un return entre le malloc et l'appel de process, donc bien une "fuite".

    Citation Envoyé par foetus Voir le message
    c'est du "C défensif"
    Au final, pas reellement "defensif". Juste "correct".

    Citation Envoyé par Sve@r Voir le message
    tu as écrit une coquille en continuant le travail dans la partie if (bytes == -1).
    et
    Citation Envoyé par Sve@r Voir le message
    Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait".
    40 lignes de code et une erreur critique (ou pas, elle sera vite detectee au moindre test). Alors que foetus est un dev experiemente. Ca illustre assez bien la limite de "le dev sait ce qu'il fait".

  9. #9
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 717
    Points : 31 028
    Points
    31 028
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Par contre, on peut critiquer le choix de design de celui qui a fait process comme ca et oblige a faire de l'allocation dynamique.
    Rien n'oblige au malloc. On passe la chaine (alloué ou statique) au process qui pourra la traiter. Je pense que le malloc (avec son free déporté) ont été mis exprès pour mieux illustrer le danger du C mal écrit.

    Citation Envoyé par mintho carmo Voir le message
    40 lignes de code et une erreur critique (ou pas, elle sera vite detectee au moindre test). Alors que foetus est un dev experiemente. Ca illustre assez bien la limite de "le dev sait ce qu'il fait".
    Ah bien vu, je me suis autobaisé
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  10. #10
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    397
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 397
    Points : 698
    Points
    698
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Rien n'oblige au malloc (enfin je crois)
    Si la fonction prend l'ownership, c'est qu'elle va appeler elle meme "free" sur le pointeur. Si c'est pas une allocation dynamique, il y a un probleme.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    void process(char *string) {
        ...
        free string; // a priori, la fonction appelle free
        ...
    }
     
    char s[BUFFER_SIZE]; 
    process(&s); // oups
    C'est d'ailleurs une des critiques du C (et en partie du C++) : le fait que l'ownership n'est pas explicite et donc que le compilateur ne peut apporter aucune garantie sur l'ownership. C'est un des points que Rust essaie de corriger, en rendant l'ownership explicite et obligatoire.

  11. #11
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 717
    Points : 31 028
    Points
    31 028
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Si la fonction prend l'ownership, c'est qu'elle va appeler elle meme "free" sur le pointeur. Si c'est pas une allocation dynamique, il y a un probleme.
    Ah ben évidemment que si "buf" n'est pas alloué il ne faut plus appeler free() !!!
    Quand je dis que la chaine peut-être allouée ou statique, je veux dire qu'on peut faire le choix de la mettre en statique mais bien entendu il faut adapter ensuite la fonction process() en conséquence.

    En allant même plus loin, la fonction process() n'a absolument pas à présumer de l'origine de la chaine et à tenter une libération. Dans le C que je pratique, le code aurait été celui-ci
    Code c : 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
    void process(char *string) {
    	... traitement string par exemple fputs(string, stdout) ...
    }
     
    int main() { 
    	char s[/* BUFFER_SIZE + 1 éventuellement mais en faisant gaffe qu'il y ait assez de place */]="Hello World\n";
    	process(s);
     
    	char *pt="Hello World\n";
    	process(pt);
     
    	char *m=malloc((BUFFER_SIZE + 1) * sizeof(*m));
    	if (m != NULL) {
    		m[BUFFER_SIZE]='\0';
    		strncpy(m, "Hello World\n", BUFFER_SIZE);
    		process(m);
    		free(m);
    	}
    }
    Mais bon, comme je l'ai dit, je pense que le code intial a été volontairement rendu abscons pour amplifier les soucis possibles.
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  12. #12
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 125
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 125
    Points : 33 028
    Points
    33 028
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    C'est d'ailleurs une des critiques du C (et en partie du C++) : le fait que l'ownership n'est pas explicite et donc que le compilateur ne peut apporter aucune garantie sur l'ownership. C'est un des points que Rust essaie de corriger, en rendant l'ownership explicite et obligatoire.
    Oui en C, mais en C++, depuis maintenant 2011 et le C++11 et std::unique_ptr, il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu. Et pour les buffers et autres chaînes de caractères, il y avait déjà std::vector ou std::string.
    Alors oui il reste sûrement des vieux codes qui traînent encore ça, où soit le code marche et personne y touche, soit il sera réécrit, et il va falloir justifier de passer ça en Rust au lieu de rester en C++, donc potentiellement recruter des personnes qui connaissent Rust parce que l'équipe en place pas forcément, voire qui devra connaître les 2 pour pouvoir naviguer dans les codes.
    Il me semble donc plus simple de rester en C++ dans un cas pareil.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  13. #13
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    397
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 397
    Points : 698
    Points
    698
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Dans le C que je pratique (...) le code intial a été volontairement rendu abscons pour amplifier les soucis possibles.
    Oui, je pense pareil pour le code abscons, la majorité des devs n'auraient pas fait une fonction qui prend l'ownership ici.

    Citation Envoyé par Bousk Voir le message
    il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu (...) il reste sûrement des vieux codes qui traînent encore ça
    Tu réponds toi même au problème. (Et je pensais aux smart ptrs dans mon "en partie")

    Et qui "trainent" ? Bonne question. Quelle est la proportion de code sans ownership dans les codes pro ? Je sais pas trop. Et on a aussi les codes "modernes" avec pointeurs nus (Qt, interfaces avec des libs C).

    Ce qui est sur, c'est qu'un langage qui va obliger a specifier l'ownership sera un avantage par rapport a un langage qui laisse les devs faire n'importe quoi. (Je précise, je suis pas fan de Rust, je ne le défend pas).

  14. #14
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 643
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 643
    Points : 10 597
    Points
    10 597
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Il y a un return entre le malloc et l'appel de process, donc bien une "fuite".
    Effectivement … mais le if est dans le commentaire (troisième code, ligne 27) ce qui n'est pas très malin
    Sûrement 1 mauvais copier-coller ou alors si on ne peut pas faire confiance aux développeurs, mais faire confiance aux moulinettes n'est pas mieux

    Citation Envoyé par mintho carmo Voir le message
    Au final, pas reellement "defensif". Juste "correct".
    Pour moi le "C défensif" c'est tester tous les retours.

    Citation Envoyé par Bousk Voir le message
    l'ownership n'est pas explicite ou connu
    Je n'ai jamais travaillé en embarqué, mais l'ownership en C ce n'est pas 1 peu "inutile"
    Dans l'exemple, on fait 1 structure avec le descripteur de fichier et le buffer. Ainsi, on "lie" les 2 variables.

    Là, comme je l'ai dit avant, le code C dans les exemples, c'est pour moi du code C d'1 développeur qui connait le C mais pas son aspect "industriel".
    Et comme le dit @Sve@r, il y a 1 impression d'amplification des erreurs.
    Oui le C "vanilla" est très "dangereux" : rien de nouveau

  15. #15
    Membre éclairé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    397
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 397
    Points : 698
    Points
    698
    Par défaut
    Citation Envoyé par foetus Voir le message
    Effectivement … mais le if est dans le commentaire (troisième code, ligne 27)
    Oui, le code copié-collé est incorrect. Mais dans le pdf, le code n'est pas correct non plus pour le free et le close.

    Citation Envoyé par foetus Voir le message
    Pour moi le "C défensif" c'est tester tous les retours.
    J'ai pas la même définition, mais peu importe.

    Citation Envoyé par foetus Voir le message
    l'ownership en C ce n'est pas 1 peu "inutile"
    A mon sens, non. Regarde la discussion qu'on a eu a propos de l'ownership de process. Dans une fonction comme process :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    void process(char *string)
    Le problème est qu'on ne peut pas savoir (sauf a lire correctement la doc, ce que personne ne fait) si le code suivant est correct ou pas :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    char string[BUFFER_SIZE];
    process(&string);
    S'il y avait un ownership explicite en C, par exemple en supprimer les pointeurs nus et en ayant des pointeurs "owned_ptr" et "not_owned_ptr", on pourrait écrire explicitement :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    void owned_process(owned_ptr<char> string);
    void not_owned_process(not_owned_ptr<char> string);
     
    char static_string[BUFFER_SIZE];
    char* dynamic_string = malloc(...);
     
    owned_process(&static_string);          // compile error
    not_owned_process(&static_string);   // ok
    owned_process(dynamic_string);       // ok
    not_owned_process(dynamic_string); // ok, mais erreur si free est oublié ensuite
    Même en C, il serait intéressant d'avoir un ownership explicite, pour le dev (savoir explicitement ce qui est attendu) et le compilateur (detecter systématiquement les erreurs, sans compter sur le fait que le dev ne fasse pas d'erreur).

  16. #16
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 569
    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 569
    Points : 15 527
    Points
    15 527
    Par défaut
    Citation Envoyé par Bruno Voir le message
    Quel est votre avis sur le sujet ?
    Que le titre "C-rusted : les avantages de Rust, en C sans les inconvénients" est très trompeur. Ce qui est proposé est très loin d'apporter au C tous les avantages du Rust. Il se contente d'apporter une version limitée du "borrow checker"

    Citation Envoyé par Sve@r Voir le message
    Le C a été conçu avec une philosophie assumée du "je laisse faire le programmeur car il sait ce qu'il fait". Donc si le programmeur fait n'importe quoi tout en restant syntaxiquement correct il n'y a aucune raison que le compilateur râle. Ce n'est donc pas la peine de venir ensuite le montrer du doigt en disant "oh regardez le compilateur n'a rien dit" car je le répète, cela était le prédicat initial et assumé de ce langage qui a, rappelons le, été créé en 1968 à l'époque où les ordinateurs n'avaient que 4Ko de RAM et qui donc peut difficilement rivaliser avec un langage du XXI° siècle. Sauf qu'en réalité il n'en a pas besoin, lui il a fait ses preuves.
    Le truc justement, c'est que cette philosophie qui se justifiait plutôt bien dans les années 70, ne correspond plus vraiment aux standards que l'on attend de nos outils modernes. De nos jours, il n'y a pas de mal à vouloir des outils qui puissent répondre à des problématiques de sécurité, d'autant plus maintenant qu'avec des langages comme Rust, ça n'implique plus de devoir renoncer à avoir un contrôle de ce qui se passe à plus bas niveau.

    Citation Envoyé par thamn Voir le message
    La version "beaucoup plus saine" du programme ne libere pas la memoire qu'il alloue? Dans tout le PDF, il n'y a pas un seul exemple qui ne fuite pas de memoire, et le pire c'est que l'allocation ne sert a rien, elle aurait pu etre statique.

    Je sais pas peut-etre c'est une erreur, mais un "analyseur" supposé rendre le code C plus robuste qui rate ça je m'en passe volontier. Et c'est fatiguant d'entendre tout le monde essayer de rendre les autres langages similaire a Rust ou clamer que c'est possible.
    C'est sans doute la rédaction très confuse de l'article qui t'induit en erreur. Je te conseille vivement de lire directement l'article source qui est beaucoup plus clair.
    Si les premiers exemples te semblent problématiques, c'est normal. Il ne s'agit pas d'exemples de code propre mais, au contraire, de code problématique pour lesquels c-rusted va pouvoir lever des warning qu'un compilateur traditionnel ne lèverait pas.
    Dans la dernière version, il n'y a en effet pas de libération de mémoire, mais cette fois c'est normal : C-rusted introduit l'annotation e_hown pour indiquer que la responsabilité de gérer la mémoire est transférée à une autre fonction. Tu peux voir qu'elle est utilisée sur le paramètre de la fonction process et donc que c'est elle qui devra se charger de la libérer la mémoire. Si le code de la fonction main la libérait aussi, ça devrait au contraire lever une alerte car ça serait une erreur de double libération.

    Citation Envoyé par smarties Voir le message
    Je n'ai pas l'impression que ça soit la fondation Mozilla qui mettent en avant RUST plus que nécessaire. Je ressens plus une volonté d'un certain nombre d'entreprises et ici d'université de mettre en avant ce langage au détriment des autres.
    En effet Rust n'a jamais eu de grand sponsors avec de gros intérêt financiers pour les pousser comme ça a pu être le cas de Sun pour Java ou Microsoft pour C#, ... et la fondation Mozilla ne met pas Rust en avant pour la simple et bonne raison quelle ne participe quasiment plus au développement du langage depuis des années. Il y a ajuste des personnes très variées qui y voient un intérêt notamment pour sécuriser les développements bas niveau.

  17. #17
    Membre émérite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 832
    Points : 2 625
    Points
    2 625
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Oui en C, mais en C++, depuis maintenant 2011 et le C++11 et std::unique_ptr, il n'y a vraiment plus aucune excuse d'avoir du code où l'ownership n'est pas explicite ou connu. Et pour les buffers et autres chaînes de caractères, il y avait déjà std::vector ou std::string.
    Alors oui il reste sûrement des vieux codes qui traînent encore ça, où soit le code marche et personne y touche, soit il sera réécrit, et il va falloir justifier de passer ça en Rust au lieu de rester en C++, donc potentiellement recruter des personnes qui connaissent Rust parce que l'équipe en place pas forcément, voire qui devra connaître les 2 pour pouvoir naviguer dans les codes.
    Il me semble donc plus simple de rester en C++ dans un cas pareil.
    Avant C++11 il y avait std::auto_ptr aussi, malgré ses défauts (qui étaient moins nombreux que la gestion manuelle, hein).
    A mon avis il est raisonnablement simple d'écrire du C++ sans bugs mémoire, si on interdit les cast C-style, les malloc, realloc, calloc et autre free, en faveur de leurs versions C++: new, delete, static_cast & compagnie.
    Pour du C++ "de base" le seul moment ou les pointeurs nus sont encore utiles depuis C++0x, c'est quand on doit passer un pointeur sans ownership, récupéré par exemple à partir de std::unique_ptr<T>::get().

    La ou le Rust a peut-être (je me base sur les on-dit, je ne connais pas rust) c'est sur la gestion du parallélisme. A ma connaissance (limitée, j'essaie d'éviter d'avoir besoin de parallélisme, surtout le multi-threadé), les outils disponibles en C++ sont franchement limités.

  18. #18
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juin 2019
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2019
    Messages : 106
    Points : 251
    Points
    251
    Par défaut
    Est-ce que c'est vraiment la faute du langage si le programmeur est nul ???
    Je passe sur les includes manquantes mais ... par exemple, tout un chacun devrait savoir qu'on teste le résultat d'une allocation. ou d'une ouverture de fichier.

    C'est simplement le B.A.-BA !

  19. #19
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 643
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 643
    Points : 10 597
    Points
    10 597
    Par défaut
    Citation Envoyé par destroyedlolo Voir le message
    Est-ce que c'est vraiment la faute du langage si le programmeur est nul ???
    Je pense que le nœud du problème c'est que pour faire de l'embarqué, il n'y a que le langage C (et sans parler de la taille de l'existant, depuis les années 70)

    Je me rappelle de la sortie de C++11, avec lequel on nous montrait des exemples C++ moderne embarqué meilleurs que le C : exécutable, code source, …
    Mais les versions sortent C++14, C++17, … mais il me semble que le C++ embarqué on n'en parle plus beaucoup

    Mais le langage C est assez difficile et très long à coder/ déboguer/ … surtout que, je pense que les exigences embarquées doivent être de + en + élevées plus le temps passe.
    Et donc, je pense qu'on essaye d'améliorer le C pour que des outils fassent toutes les vérifications "usuelles" sans erreur … et indirectement d'avoir des développeurs avec des profils moins experts/ rares/ … qui excellerait également la vitesse des développements.

    Et dans 1 autre fil de discussion je parlais aussi de l'émergence en "conception électronique" de la Chine face à l'hégémonie américaine : création de processeur, création de systèmes d'exploitation, …
    Mais pour l'instant, il faut des équipes ultra formées et ultra expérimentées pour cela.

  20. #20
    Membre actif
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juin 2019
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2019
    Messages : 106
    Points : 251
    Points
    251
    Par défaut
    Citation Envoyé par foetus Voir le message
    Je pense que le nœud du problème c'est que pour faire de l'embarqué, il n'y a que le langage C (et sans parler de la taille de l'existant, depuis les années 70)
    Ben pas vraiment : j'en fais pour le fun depuis la fin des années 80, et il y avait déjà a l'époque aussi du BASIC (p.e. le fameux 8051), et de nos jours, il y a aussi Lua et malheureusement le uPython. Malheureusement car je trouve qu'il éloigne beaucoup trop du hard et donc on arrive à se retrouver avec des usines a gaz non optimisés.

    Citation Envoyé par foetus Voir le message
    Je me rappelle de la sortie de C++11, avec lequel on nous montrait des exemples C++ moderne embarqué meilleurs que le C : exécutable, code source, …
    Mais les versions sortent C++14, C++17, … mais il me semble que le C++ embarqué on n'en parle plus beaucoup
    Ben avec l'Arduino, au contraire, ca se démocratise. Le problème est que ca méthode de développement est très éloigné du C/C++ classique (avec son IDE) et qu'on a, à nouveau, beaucoup de code vraiment pas terrible. Mais les évolutions de GCC profitent aussi à cet écosysteme. Il en va aussi de même pour d'autres solutions. Mais en effet, ce n'est pas trop présent dans les discussions.

    Citation Envoyé par foetus Voir le message
    Mais le langage C est assez difficile et très long à coder/ déboguer/ … surtout que, je pense que les exigences embarquées doivent être de + en + élevées plus le temps passe.
    Bien au contraire, les ST32, les AVR, les ESP ont des ressources sans commune mesure avec ce qui se faisait par exemple il y a seulement une décennie. D'où par exemple la prolifération de code uPython non optimisé voir mal conçus.
    Il en va de même dans l'industrie (mon nouveau taf) : on doit géré des évènements de plus en plus rapides, mais même sur les automates, on n'a plus les restrictions de ressources qu'on avait dans le passé.

    Citation Envoyé par foetus Voir le message
    Et donc, je pense qu'on essaye d'améliorer le C pour que des outils fassent toutes les vérifications "usuelles" sans erreur … et indirectement d'avoir des développeurs avec des profils moins experts/ rares/ … qui excellerait également la vitesse des développements.
    Justement, c'est ce qui me gêne. Sur de l'embarqué, qui aurait envi d'avoir des trucs aussi instables que sur PC ? Par exemple, je bosse actuellement sur la modernisation d'un réseau de distribution. Non seulement, l'espérance de vie du bigou est en décennies, mais c'est un système critique, chaque indispo non prévu à des impacts importants, voir critique dans certains cas.

Discussions similaires

  1. Comprendre les avantages et les inconvénients des Big Data
    Par Community Management dans le forum Big Data
    Réponses: 0
    Dernier message: 28/08/2016, 01h32
  2. Réponses: 6
    Dernier message: 07/08/2014, 21h23
  3. Réponses: 1
    Dernier message: 11/03/2012, 15h36
  4. métier de développeur ..les avantages et les inconvénients
    Par said-developpeur dans le forum Etudes
    Réponses: 2
    Dernier message: 22/09/2009, 14h46
  5. Réponses: 2
    Dernier message: 23/11/2008, 19h18

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