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 :

CppCon 2016 : persuader les programmeurs de C de migrer vers C++


Sujet :

C++

  1. #1
    Expert éminent sénior
    Avatar de Coriolan
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2016
    Messages
    701
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Sarthe (Pays de la Loire)

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

    Informations forums :
    Inscription : Mai 2016
    Messages : 701
    Points : 51 808
    Points
    51 808
    Par défaut CppCon 2016 : persuader les programmeurs de C de migrer vers C++
    CppCon 2016 : Persuader les programmeurs de C de migrer vers C++
    Par Dan Saks

    C++ permet l’utilisation de l’ensemble des bibliothèques C existantes de telle sorte que beaucoup croient qu’ils sont liés l’un à l’autre, et ce n’est pas faux. Migrer du code de C à C++ est une tâche assez simple. En plus, cette migration elle-même peut s’avérer bénéfique dans le sens où elle permet d’exposer les conversions incertaines qui pourraient causer des bogues latents par la suite. Après la migration, le code a sous C++ la même performance qu’il a dans C, mais maintenant il est possible d’avoir accès à un lot de fonctionnalités qu’on peut utiliser afin d’implémenter des améliorations.

    Le langage C++ a eu un énorme succès dans de nombreuses applications et domaines, il n’appartient à personne et par conséquent n’importe qui peut l’utiliser sans besoin d’une autorisation ou obligation de payer pour avoir le droit d’utilisation, ce qui en fait l’un des langages les plus populaires ayant le support d’une variété de plateformes matérielles et de systèmes d’exploitation. Mais malgré ce succès, C reste encore le langage privilégié des développeurs dans certains domaines comme les applications embarquées, de l’automobile et ceux de l’aéronautique. Dans beaucoup de cas, des projets n’admettent pas le C++ en raison du scepticisme des managers qui considèrent que les risques sont beaucoup plus importants que les avantages pour considérer le langage comme une option. Autrement dit, il y a toujours cette perception négative sur C++ chez certains programmeurs, même si elle n'est plus viable forcément.

    Afin de tacler cette problématique, Dan Saks se demande comment la communauté C++ va surmonter cette résistance. En s’appuyant sur la science cognitive, la linguistique, la psychologie et bien sûr l’informatique ; il cherche à offrir des suggestions sur la façon de rendre C++ plus convaincant pour les programmeurs de C. Dan Saks est l’un des experts les plus notables de C et C++ et leur usage dans le développement de systèmes embarqués.


    Source : YouTube

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi :

    La rubrique C++ : Forum C++, Cours et tutoriels C++, FAQ C++, ...
    CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++ et s'intéresse à son passé, à son présent mais aussi à son futur
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    1 856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 1 856
    Points : 3 570
    Points
    3 570
    Par défaut
    Citation Envoyé par Coriolan Voir le message
    Qu'en pensez-vous ?
    Jamais ! JAMAIS ! AH AH AH AH !!! (je chauffe déjà et on est que mardi)

    Bon ...
    Perso, a priori je ne vois pas tellement d'avantage à passer au C++, toute la POO me semble assez aisément dispensable.
    Par contre j'ai pas encore pu regarder la vidéo, je verrai ça quand j'aurai du temps devant moi (1h30 quand même).
    Plus je connais de langages, plus j'aime le C.

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    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 627
    Points : 10 551
    Points
    10 551
    Par défaut
    Citation Envoyé par jopopmk Voir le message
    toute la POO me semble assez aisément dispensable.
    Je mets 1 pièce que tu tapes à côté

    Je pense plutôt qu'il insiste sur la RAII et sur le fait qu'en C++11 toutes les allocations dynamiques sont cachées: "code safer" ou un truc approchant

  4. #4
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    1 856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 1 856
    Points : 3 570
    Points
    3 570
    Par défaut
    Citation Envoyé par foetus Voir le message
    Je mets 1 pièce que tu tapes à côté

    Je pense plutôt qu'il insiste sur la RAII et sur le fait qu'en C++11 toutes les allocations dynamiques sont cachées: "code safer" ou un truc approchant
    Je parle de mon cas : le seul intérêt serait d'avoir la facilité de conception qu'offre la POO, mais même là ça me motive pas.
    J'espère effectivement qu'en 1h30 il a des arguments un peu plus chiadés que "la POO c'est trop d'la boulette"

    PS : moi j'aime mes pointeurs pas safe et mes alias disséminés de partout
    Plus je connais de langages, plus j'aime le C.

  5. #5
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    138
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 138
    Points : 406
    Points
    406
    Par défaut
    Le seul frein que je vois est la complexité du langage C++ et ça ne va pas en s’arrangeant. C'est clair que c'est plus complexe que le C et ça peut freiner une migration malgré les avantages du C++. Il faut tenir compte de la disponibilité des compétences en C++.

  6. #6
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Avril 2002
    Messages
    2 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 789
    Points : 18 930
    Points
    18 930
    Par défaut
    Citation Envoyé par ParseCoder Voir le message
    Le seul frein que je vois est la complexité du langage C++ et ça ne va pas en s’arrangeant. C'est clair que c'est plus complexe que le C et ça peut freiner une migration malgré les avantages du C++. Il faut tenir compte de la disponibilité des compétences en C++.
    Ça me fait penser à ce débat : C++ aujourd'hui est-il comme Fortran ? Aurait-il atteint ses limites ? Un ingénieur explique pourquoi il ne s'adonne plus beaucoup au C++ moderne
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  7. #7
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    On retrouve les présentations que Dan Saks avait données pour les Code::Dive 2015. Je reprends ce que je disais (il y a d'autres présentations pour le public qui doute des apports du C++ en embarqué) ici: http://www.developpez.net/forums/d32...r/#post8505022

    Citation Envoyé par Luc Hermitte Voir le message
    Tout d'abord les conférences de Dan Saks, un avocat de longue date pour employer le C++ en embarqué. Il y traite de mindset, c'est à dire, d'états d'esprit, de philosophie, et d'a priori. Il explique que les avocats du C++ ne savent pas parler aux développeurs C et en particulier à ceux qui font de l'embarqué. En particulier il a soulevé le quiproquo sur l'investigation : le développeur C++ met en avant un type (qui en plus n'est pas forcément le plus adapté) que le développeur C trouve inexploitable pour débugguer les soucis. A la place il aurait pu mettre en avant que le nouveau type est là pour intercepter les soucis au plus tôt (en compilation), afin de réduire drastiquement les besoins de debuggage.

    Dans ses conférences, il donne des exemples où le C++ apporte de la sécurité grâce à son typage moins laxiste, et ce sans dégrader les performances.
    - Sonner Rather that Later:

    - Representating Memory Mapped Devices as Objects:
    Bref, l'OO, OSEF ici. Son premier point est que les développeurs C ont des attentes et des habitudes, et que les dev C++ ne savent pas leur expliquer en quoi le C++ est une alternative qui pourrait leur convenir. Et non, la réponse ne se résume pas à "OO". C'est d'ailleurs plus des surcouches génériques et sécurisées qui sont mises en avant, en appuyant le fait que l'on refile la tâche de l'analyse au compilateur au lieu de passer du temps à débugger.

    Bref, mettez vos a priori de côté et regardez ces confs avant de dire "toute la POO me semble assez aisément dispensable". Le C++ n'est plus depuis longtemps un C avec juste de l'OO en plus.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  8. #8
    Membre averti
    Homme Profil pro
    Lycéen
    Inscrit en
    Décembre 2014
    Messages
    106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Lycéen

    Informations forums :
    Inscription : Décembre 2014
    Messages : 106
    Points : 322
    Points
    322
    Par défaut
    Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ? Une vidéo pour inciter les pprogrammeurs C++ à passer au Rust me paraitrait plus utile...

  9. #9
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Consultant en Systèmes Embarqués
    Inscrit en
    Avril 2002
    Messages
    3 185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Consultant en Systèmes Embarqués
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Avril 2002
    Messages : 3 185
    Points : 11 551
    Points
    11 551
    Par défaut
    [...]Mais malgré ce succès, C reste encore le langage privilégié des développeurs dans certains domaines comme les applications embarquées, de l’automobile et ceux de l’aéronautique. Dans beaucoup de cas, des projets n’admettent pas le C++ en raison du scepticisme des managers[...]
    Oula... ça n'a rien a voir avec le scepticisme.
    C'est simplement que les managers savent ce qu'est le domaine de l'embarqué contrairement a Dan Saks qui réduit les systèmes embarqués aux nano-PC embarquant un OS et c'est justement une erreur.

    Pourquoi je dis ça ? Déjà parce que j'étais développeur de ce côté là justement mais aussi parce que :

    Dans la vie courante, qui dit systèmes embarqués dit : 5% de gros microcontrôleurs/SoC (dans le genre Raspberry) avec un OS et 95% de microcontrôleurs sans aucun système d'exploitation.

    Chez vous les 5% c'est votre box internet, votre téléphone portable, vos PC, votre télévision et votre console et c'est a peu prés tout pour les gens normalement connecté.
    Les 95% c'est dans vos voitures, votre thermostat, votre chaudière, chauffage, votre frigo, micro-onde, réveil, thermomètre, dans les capteurs de fumée, les jouets des enfants .... j'arrête là car il y a aujourd'hui des petits micro-contrôleurs programmés en langage C ou assembleur dans tout ce qui vous entours et qui est électronique. C'est devenu tellement pas cher ces bestioles que même lorsqu'il y en a pas besoin, et bien on en trouve un.

    En gros on peut voir ça comme dans une alarme où on aurait une centrale avec un OS (là le C++ a un réel avantage) pour plein de capteurs intelligents (programmés en C) qui n'embarque aucun OS.


    Afin de tacler cette problématique, Dan Saks se demande comment la communauté C++ va surmonter cette résistance. En s’appuyant sur la science cognitive, la linguistique, la psychologie et bien sûr l’informatique ; il cherche à offrir des suggestions sur la façon de rendre C++ plus convaincant pour les programmeurs de C. Dan Saks est l’un des experts les plus notables de C et C++ et leur usage dans le développement de systèmes embarqués.[...]
    Qui a déjà programmé sur un microcontrôleur sait que si il passe au C++ alors ça sera pour utiliser que ce qui est commun au langage C donc il n'y a pas d'intérêts.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  10. #10
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    @Vincent, regarde la présentation de Bartosz Szurgot alors
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  11. #11
    Membre éprouvé
    Profil pro
    Inscrit en
    Décembre 2004
    Messages
    585
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2004
    Messages : 585
    Points : 1 138
    Points
    1 138
    Par défaut
    Tant qu'à choisir un truc un peu moderne qui a plus ou moins des airs de C, pourquoi pas plutôt D ?
    L'avis publié ci-dessus est mien et ne reflète pas obligatoirement celui de mon entreprise.

  12. #12
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2008
    Messages : 19
    Points : 86
    Points
    86
    Par défaut
    Citation Envoyé par Vincent PETIT Voir le message
    Qui a déjà programmé sur un microcontrôleur sait que si il passe au C++ alors ça sera pour utiliser que ce qui est commun au langage C donc il n'y a pas d'intérêts.
    L'ignorance fait encore des ravages...

    Comme à dit Luc Hermitte, regarde cette vidéo. Et pour faire court, le C++ permet d'obtenir du code à la fois plus court (et plus lisible), un binaire plus léger et plus rapide car le C++ est un langage un poil plus abstrait, plus explicite (c'est le terme qui le définit le mieux face au C), permettant au compilateur de faire de meilleures optimisations justement car tu, en tant que développeur, lui donnes plus d'informations et de garanties !!!

    Citation Envoyé par Thorna Voir le message
    Tant qu'à choisir un truc un peu moderne qui a plus ou moins des airs de C, pourquoi pas plutôt D ?
    Le D a des ajouts supplémentaires face au C++ vraiment cools pour rendre le langage encore plus explicite (donc plus optimisable par le compilateur) mais (il y a quelques mais), il embarque un garbage collector, tu perds donc le contrôle de la gestion de ta mémoire (alors qu'avec un bon shared_ptr ou unique_ptr, tu sais encore ce qu'il se passe réellement), et autant il doit être disponible sur les principaux OS, pour le monde de l'embarqué, c'est une tout autre histoire.

    Bref vive le modernC++ (à partir de C++11) !

    * n'oubliez pas les constexpr, très pratique, les rvalue reference, gros gain de perfo, et j'en oublie d'autre...

  13. #13
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Consultant en Systèmes Embarqués
    Inscrit en
    Avril 2002
    Messages
    3 185
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Consultant en Systèmes Embarqués
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Avril 2002
    Messages : 3 185
    Points : 11 551
    Points
    11 551
    Par défaut
    Citation Envoyé par Roadkiller Voir le message
    L'ignorance fait encore des ravages...
    Tu n'as jamais touché a un micro-contrôleur et ça se voit !

    Je ne suis pas entrain de dire que le C++ est moins bien que le C, je dis que sur 95% des microcontrôleurs que tu retrouves dans ton quotidien (qui n'ont pas d'OS) tous les avantages indéniables que le C++ a par rapport au C, ne te servent strictement a rien. Sur un microcontrôleur, tu gères du matériel et des registres, y a pas de flux, y a pas d'exception a gérer, y a pas d'allocation dynamique de la mémoire, y a déjà pas beaucoup de mémoire donc tu ne fais surtout rien d'abstrait, tu programmes en procédurale et pas en objets, y a pas de thread ni toutes les choses complexes que tu connais toi sur un PC :
    Exemple sur un ATMEGA328P (le micro de Arduino UNO)
    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
    20
    21
    22
    #include <avr/io.h>
    #include <util/delay.h>
     
    int main (void)
    {
     /* mettre la pin 1 du PORTB du micro en sortie */
     DDRB |= 0x01; 
     
     while(1) {
     /* mettre la pin 1 du PORTB du micro à 1 (logique) */
      PORTB |= 0x01;
     
     /* attendre 1 s */
      _delay_ms(1000);
     
     /* mettre la pin 1 du PORTB du micro à 0 (logique) */
      PORTB &= ~0x01;
     
     /* attendre 1 s */
      _delay_ms(1000);
     }
    }

    DDRB c'est le nom d'un registre dans le micro, c'est le registre de direction de chaque broche du port B qui fait 8 bits et suivant que tu mets à 1 ou 0 les bits qui le compose ça configure chaque broche en sortie ou en entrée.
    PORTB c'est le nom d'un registre aussi, c'est le registre de sortie du PORTB et si tu as mis une broche en sortie via le registre DDRB alors tu peux mettre à 1 ou à 0 cette sortie. Si DDRB est configuré en entrée alors PORTB ne peut être qu'en lecture.

    Tout ça pour dire que dans tous les microcontrôleurs qu'on trouve partout, tout est registre.
    - Le Timer
    - Le convertisseur analogique numérique
    - Les ports d'entrées/sorties
    - Les bus de communications UART, SPI et I2C

    Le programme est hyper déterministe il consiste très souvent en du traitement du signal et de la communication dans 95% des cas les microcontrôleurs sont petits/moyens (capteurs par exemple) et le C++ n'apporte aucun avantage par rapport au C car ce dont tu as besoin c'est d'être proche du matériel.

    Citation Envoyé par Roadkiller Voir le message
    [...]le C++ est un langage un poil plus abstrait, plus explicite (c'est le terme qui le définit le mieux face au C), permettant au compilateur de faire de meilleures optimisations justement car tu, en tant que développeur, lui donnes plus d'informations et de garanties !!!
    C'est justement ce que tu ne peux pas te permettre en étant sur le matériel, tu as des contraintes de temps a prendre en compte. Lorsque tu as réglé ton timer pour qu'il déborde toutes les 1ms alors il peut te générer une interruption. Dans cette interruption tu es amené a insérer du code dont tu as sacrément intérêt a maîtriser le timing puisque ce code sera exécuter au rythme du débordement du timer donc si le code s'exécute en plus de 1ms, on sent qu'il va y avoir un sacré problème. Pire encore tu peux être amené a attendre le matériel (handshaking) et c'est là où l'abstraction et l'optimisation du compilateur peut poser de gros problème.

    Par contre !
    Et c'est ça que je dis, d'ailleurs je me cite :
    Citation Envoyé par Vincent PETIT
    En gros on peut voir ça comme dans une alarme où on aurait une centrale avec un OS (là le C++ a un réel avantage)
    Exemple, ton micro doit enregistrer des données sur une clé USB au format FAT ou avoir un serveur Web embarqué alors là tu as besoin d'un langage comme C++ mais tu es dans les 5% des microcontrôleurs, c'est à dire les gros trucs balaises.

    Merci pour cette vidéo Luc.
    J'ai tout regardé sauf les questions sur la fin, la comparaison portait sur des programmes C et C++ exécutés un panel de processeurs/micro-contrôleurs très pertinents ! AMD, ARM11 (32 bits), ARM Cortex M0 (32 bits) et AVR de chez Atmel (8 bits) et le compilateur était GCC mais la seule chose que cette longue conférence m'apprend c'est que le compilateur GCC semble mieux optimiser le code C que C++ !

    Citation Envoyé par Roadkiller Voir le message
    Et pour faire court, le C++ permet d'obtenir du code à la fois plus court (et plus lisible), un binaire plus léger et plus rapide
    Et si le compilateur n'avait pas été GCC ? Mais plutôt IAR ou Keil ou le compilateur propriétaire du fabricant ? Dans cette vidéo il n'y a pas vraiment d'exemple concret de la vraie plus value de C++ sur un micro.


    Pour faire entrer le C++ dans les systèmes embarqués il faudrait convaincre les 95% des développeurs électroniciens qui n'en n'ont malheureusement pas besoin.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  14. #14
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2011
    Messages
    1 856
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 1 856
    Points : 3 570
    Points
    3 570
    Par défaut
    J'ai commencé par la dernière vidéo présentée par Luc Hermitte (celle de Bartosz Szurgot) qui est vraiment intéressante. Ça rejoint d'ailleurs pas mal ce que dit Roadkiller. Maintenant j'ai toujours quelques remarques en tête sur ce qu'il dit :
    - son premier comparo n'est pas fait avec un C particulièrement optimisé (mais le C++ ne "semble" pas l'être non plus, cf. STL, c'est la beauté du truc),
    - il nous parle des options de compil' pour le C++, pas pour le C,
    - pour tirer le meilleur du C++ il faut bien connaitre son compilo et parfois utiliser des astuces qui ne sautent pas aux yeux dans une conception OO "théorique" qu'on trouverait dans un MCD,
    - on peut se retrouver avec du code pas nécessairement très compréhensible de prime abord (j'imagine un stagiaire qui arrive sur un code et se dit : je vais simplifier tout ce charabia -ce qui aura l'effet inverse une fois compilé) ;bon, en C j'ai écrit des codes que même moi je comprends plus ...
    - il parle super vite ><

    En conclusion je reste quand même un peu sur mon premier avis : on peut faire un code en langage X plus performant qu'en C, si le premier est très bien codé et le second pas trop. En tout cas ça me donne un peu envie de refaire du C++ alors que c'était pas gagné ^^
    Plus je connais de langages, plus j'aime le C.

  15. #15
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Citation Envoyé par Vincent PETIT Voir le message
    Je ne suis pas entrain de dire que le C++ est moins bien que le C, je dis que sur 95% des microcontrôleurs que tu retrouves dans ton quotidien (qui n'ont pas d'OS) tous les avantages indéniables que le C++ a par rapport au C, ne te servent strictement a rien. Sur un microcontrôleur, tu gères du matériel et des registres, y a pas de flux, y a pas d'exception a gérer, y a pas d'allocation dynamique de la mémoire, y a déjà pas beaucoup de mémoire donc tu ne fais surtout rien d'abstrait, tu programmes en procédurale et pas en objets, y a pas de thread ni toutes les choses complexes que tu connais toi sur un PC :

    [...]
    Le programme est hyper déterministe il consiste très souvent en du traitement du signal et de la communication dans 95% des cas les microcontrôleurs sont petits/moyens (capteurs par exemple) et le C++ n'apporte aucun avantage par rapport au C car ce dont tu as besoin c'est d'être proche du matériel.
    Si mes souvenirs sont bons, pas mal des exemples de Dan Saks concernent justement l'accès sécurisé à des registres. Son angle d'approche consiste à remplacer la détection d'erreur de manipulation/mélange de registres au runtime (phase de débugging profondément enracinée dans le mindset C-Embarqué selon lui), par une détection d'erreurs à la compilation, et ce tout en maintenant des performances identiques, voire des binaires strictement identiques.


    Citation Envoyé par Vincent PETIT Voir le message
    Merci pour cette vidéo Luc.
    J'ai tout regardé sauf les questions sur la fin, la comparaison portait sur des programmes C et C++ exécutés un panel de processeurs/micro-contrôleurs très pertinents ! AMD, ARM11 (32 bits), ARM Cortex M0 (32 bits) et AVR de chez Atmel (8 bits) et le compilateur était GCC mais la seule chose que cette longue conférence m'apprend c'est que le compilateur GCC semble mieux optimiser le code C que C++ !


    Et si le compilateur n'avait pas été GCC ? Mais plutôt IAR ou Keil ou le compilateur propriétaire du fabricant ? Dans cette vidéo il n'y a pas vraiment d'exemple concret de la vraie plus value de C++ sur un micro.
    La vidéo de Bartosz rapportait le contraire si mes souvenirs sont bons: des binaires et des vitesses identiques, voire plus courts d'un octet (sans qu'il sache pourquoi dans le cas du C++)

    Après il est vrai que quand les fournisseurs du hardware ne fournissent pas de compilo C++ de qualité et qu'il n'y a pas du support par g++ ou clang+++, ça limite!

    Citation Envoyé par Vincent PETIT Voir le message
    Pour faire entrer le C++ dans les systèmes embarqués il faudrait convaincre les 95% des développeurs électroniciens qui n'en n'ont malheureusement pas besoin.
    On revient sur les videos de Dan Saks: "qui a besoin de quoi?" Comment passer de l'état d'esprit "je tape un truc, je compile, et enfin je commence à travailler i.e. le débugging commence" à "je corrige jusqu'à ce que cela compile et alors cela a de fortes chances d'êtres correct"? (Ce qui correspond à la boutade que j'ai souvent entendu pour Ada: "si ça compile, alors c'est correct")

    Citation Envoyé par jopopmk Voir le message
    J'ai commencé par la dernière vidéo présentée par Luc Hermitte (celle de Bartosz Szurgot) qui est vraiment intéressante. Ça rejoint d'ailleurs pas mal ce que dit Roadkiller. Maintenant j'ai toujours quelques remarques en tête sur ce qu'il dit :
    a- son premier comparo n'est pas fait avec un C particulièrement optimisé (mais le C++ ne "semble" pas l'être non plus, cf. STL, c'est la beauté du truc),
    b- il nous parle des options de compil' pour le C++, pas pour le C,
    c- pour tirer le meilleur du C++ il faut bien connaitre son compilo et parfois utiliser des astuces qui ne sautent pas aux yeux dans une conception OO "théorique" qu'on trouverait dans un MCD,
    d- on peut se retrouver avec du code pas nécessairement très compréhensible de prime abord (j'imagine un stagiaire qui arrive sur un code et se dit : je vais simplifier tout ce charabia -ce qui aura l'effet inverse une fois compilé) ;bon, en C j'ai écrit des codes que même moi je comprends plus ...
    e- il parle super vite ><

    f- En conclusion je reste quand même un peu sur mon premier avis : on peut faire un code en langage X plus performant qu'en C, si le premier est très bien codé et le second pas trop. En tout cas ça me donne un peu envie de refaire du C++ alors que c'était pas gagné ^^
    a- Certains ont effectivement reproché qu'un vrai code aurait utilisé memcpy/memset. Maintenant, certaines implémentations de la SL vont remplacer les algo standard par des appels à memset/memcpy, avec garanties faites à la compilation en plus, et sans instructions dues à l'abstraction en plus
    b- Je dirai: à priori les mêmes, après tout, il voulait démontrer que le C était plus rapide, et les binaires plus petits au départ
    c- Il faut s'éloigner du OO à tout prix. Le premier gain du C++ réside dans le typage renforcé. Un second gain, est qu'avec ce typage renforcé, et le step-0 de l'OO (la gestion des invariants grâce à l'encapsulation), on peut se débarrasser plus simplement de la programmation défensive qui impacte les performances -- et qui est exigée dans beaucoup de projets embarqués.
    d- L'idée avec le C++ n'était pas de complexifier mais au contraire de simplifier. Cf aussi les videos CppCon 2015 ou 14 de gars chez Microsoft qui ont réécrit leur lib C en ... C++ pour factoriser l'enfer des 150 versions de printf & cie.
    e- Oui. C'est clair. Mais j'avais bien aimé. Je n'arrive pas du tout à suivre des orateurs plus tranquilles comme Sean Parent.

    f- je ne pense pas que son objectif était de présenter du C mal codé (au détail de la boucle manuelle en place de memcpy), mais du code idiomatique.


    Ca me rappelle une autre conf récente au sujet des exceptions VS codes de retour:
    Beaucoup sont persuadés que les exceptions sont plus lentes. Je suis intimement convaincu du contraire. Au départ, je me disais juste que l'on avait moins de branchements dans le cas nominal (OSEF de la vitesse en cas de situation anormale, hors embarqué) ce qui est mieux pour le pipeline, et j'ai découvert là, qu'en plus cela permettait de faire tenir plus de code nominal dans le cache d'instructions, ce qui est bon aussi. Les seuls bémols étant donc le binaire plus gros, et le surcoût titanesque en cas d'exception. Ce qui hors de l'embarque critique (avec vies en jeu) est complètement tolérable.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  16. #16
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    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 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par jopopmk Voir le message
    Je parle de mon cas : le seul intérêt serait d'avoir la facilité de conception qu'offre la POO, mais même là ça me motive pas.
    J'espère effectivement qu'en 1h30 il a des arguments un peu plus chiadés que "la POO c'est trop d'la boulette"
    La POO par héritage est loin d'être le seul intérêt du C++, je dirais même que c'est certainement une des fonctionnalités les plus dispensables. Il y a énormément de choses intéressantes en C++ avec entre autre les templates, les smart pointer, la surcharge, ...

    Citation Envoyé par derderder Voir le message
    Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ? Une vidéo pour inciter les pprogrammeurs C++ à passer au Rust me paraitrait plus utile...
    Il y en a déjà pas mal de videos qui présentent les bienfaits du Rust, mais on parle de présentation qui ont eu lieu à la CppCon. Ce n'est évidement pas l'endroit ou on va faire de la pub pour les autres langages, c'est de bonne guerre.

    C'est vrai que le Rust a pas mal d'arguments à proposer à ceux qui souhaiteraient regarder au delà de ce que propose le C. C'est un langage plus simple que le C++ sans la lourdeur que peut avoir l'orienté objet (avec héritage). Il propose aussi une sécurité bien meilleure que le C++, même avec ses "pointeurs intelligents".

    C'est quand même plus facile de convaincre un utilisateur C de faire le pas vers le C++ que vers un autre langage, vu qu'il reprend à 99% la syntaxe et les bibliothèques de C. Cependant c'est a double tranchant car pour faire du code C++ idiomatique, il vaut mieuux oublier la plupart des chose que l'on faisait en C

    Citation Envoyé par Thorna Voir le message
    Tant qu'à choisir un truc un peu moderne qui a plus ou moins des airs de C, pourquoi pas plutôt D ?
    Le problème du D c'est qu'il n'est pas du tout adapté à l'embarqué à moins de désactiver toutes les fonctionnalités intéressantes, notamment à cause du GC. Il y a un effort en cours pour essayer de remédier à ça mais il est bien en dessous de ce que proposent C, Rust ou même C++.

  17. #17
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Il commence par comparer un code C et C++ pour montrer qui est le plus rapide. Et je me suis arrêté là quand j'ai vu le code...
    Pourquoi ne pas utiliser un memset qui sera d'un point de vue assembleur équivalent à fill ?
    Quand on fait de l'embarqué on raisonne bas niveau dans la grande majorité des cas car on est contraint en mémoire et en temps (pas forcément vrai dans le second cas).
    Là je trouve qu'il raisonne plutôt cours basique d'université en rédigeant son code...
    Il fait un code propre mais pas forcément au mieux. Ce monsieur a-t-il déjà regardé ce que donnait ses programmes en assembleur ?
    A-t-il déjà eu à améliorer sa façon d'écrire du C pour gagner deux-trois cycles de processeur dans un traitement afin de se caler avec un cycle d'horloge FPGA externe ou autre ?
    J'en doute...
    Bref il veut simplement faire adopter le C++ qui est devenu son nouveau dada rien de plus selon moi.

    On s'est déjà posé la question au boulot lors de l'ajout d'un nouveau processeur et d'un logiciel.
    On a travaillé avec deux experts du langage pour mettre au point certains de nos algorithmes avec une méthodologie C++.
    Le constat mémoire était sans appel... Ils ont bossé cinq fois plus de temps et ont recommencé plein de fois pour obtenir de bonnes performances afin d'optimiser au mieux la mémoire et le temps d'exécution que nous en utilisant du C (dont l'algo se faisait en trois heures de travail pour un gars qui a deux-trois ans d'expériences en C embarqué).
    Donc oui le C++ peut être un équivalent du C. Mais il faut être tellement expert de ce langage et de ce que cela donne en assembleur qu'à part quelques experts dans le monde personne ne peut le faire.

    Donc le C a encore de très beaux jours devant lui pour les applications embarquées temps réel contraintes.
    Le C++ apporte de beaux outils mais un abstraction qui n'est pas souhaitable dans notre domaine.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  18. #18
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    Juillet 2008
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : Juillet 2008
    Messages : 414
    Points : 1 508
    Points
    1 508
    Par défaut c++ pour quoi faire ?
    Je fais de l'électronique en amateur principalement avec des micro-controlleurs. Vu la petitesse des projets et la place très limitée sur les microcrontrôlleurs, je n'utilise pas d'allocation dynamique, toutes les variables sont affectées dès le départ ; comme ça, pas de risque de dépassement de la toute petite mémoire. Certains me diront que les variables globales c'est le mal...
    De même, pas la peine de faire de l'objet si c'est pour avoir une seule classe contenant l'ensemble du programme. Donc, pour mes microcontrolleurs, je reste au C (microchip) et à l'assembleur (8051) et le C++ ne présente aucun intérêt.

  19. #19
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    Le C++ présente l'intérêt de remplacer des heures de déboggages, ou d'écriture de test unitaires pour des babioles, par des baffes données par le compilateur. Il va râler bien avant sur nos bêtises. Et c'est justement une couche d'abstraction qui a facilement un coût nul côté assembleur.

    @transgohan, tu parles de quelle vidéo?
    Si c'est au sujet de celle de Bartosz Szurgot. Il faut savoir que l'implémentation des algos standard chez libstdc++ (la SL C++ de GNU) fait que std::fill_n sur des char va être en fait remplacée par __builtin_memset, et std::copy sera remplacée pas __builtin_memmove à chaque fois que possible -- i.e. sur tous les types employables en C.
    Dans le cas des codes de Dan Saks, cette fois il n'en a pas donnés beaucoup, mais comme il disait : il avait fait valider ses codes C et C++ par des professionnels de l'embarqué avant de réaliser ses benchs.

    Après, comme en C, il faut monter en compétence pour écrire du code optimisé. Il est normal que cela ne soit pas aussi efficace la première fois que l'on fait l'exercice tant que l'on n'a pas expérimenté les diverses nouvelles possibilités qui s'offrent à nous. Ils ont peut-être passé 5 fois plus de temps la première fois, je doute qu'il en aurait été de même les fois suivantes. Accessoirement, ils perdent des possibilités d'optimisation (cf pointeurs de fonction VS template, l'exemple typique qsort VS std::sort ; élimination sécurisée de la programmation défensive (fonctions qui testent toujours toutes leurs entrées, "parce que l'on ne sait jamais, le pointeur reçu pourrait être nul") ; ...)
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  20. #20
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    780
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mai 2006
    Messages : 780
    Points : 1 176
    Points
    1 176
    Par défaut
    A la limite la conférence "un jeu pour C++17 sur Commodore 64", qui est en fait très semblable à ce qu'on ferait pour de l'embarqué (genre arduino), montre bien ce qu'on peut faire avec du C++ moderne bien plus puissant que du C.



    Tout ce qu'il dit sur les registres etc je l'ai appliqué à un dev arduino donc non, le C++ apporte bien des choses pour l'embarqué (grâce aux constexpr, grâce aux templates, tout ce qui permet de pre-processer tout un tas de truc et rendre le code super lisible). Et faire des classes avec des méthodes, c'est souvent plus clair aussi, pour tout ce qui est concret (une classe Affichage LCD, une classe Timer, etc.. pas besoin d'héritage ni d'exception c'est sûr).

    vous pouvez regarder ici: http://www.stroustrup.com/performanceTR.pdf section "Hardware addressing".

    Ca permet d'avoir du code générique qui peut gérer plusieurs processeur par exemple. On peut écrire des choses comme ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    // à partir de définitions comme celles là:
    typedef avrport< reinterpret_cast< address_type >( const_cast< uint8_t* >(( &PORTB ))),
                         reinterpret_cast< address_type >( const_cast< uint8_t* >(( &PINB ))),
    reinterpret_cast< address_type >( const_cast< uint8_t* >(( &DDRB ))) > PortB;
     
    // on peut spécifier explicitement des éléments de notre plateforme (je coupe les détails)
    typedef platform::io_pin< platform::PortB, 5 > DebugLed;
     
    // et l'utiliser directement
    DebugLed::set();
    par ex. Sans aucun overhead ni indirection dans le code assembleur.

    Grâce aux constexpr et aux static_assert, je peux faire un vérificateur d'EEPROM par exemple, qui va vérifier qu'on écrit jamais (par erreur) dans une mauvaise zone ou qu'aucune zone dédié ne dépasse sur une autre et mettra une erreur de compil dans ce cas.

    Grâce aux variadic templates, je peux refaire exactement boost::msm (Meta State Machine) pour ma machine à état qui est vérifié à la compilation.

    Mais sinon, ouais, aucune utilité pour l'embarqué...

Discussions similaires

  1. Réponses: 1
    Dernier message: 01/10/2016, 22h02
  2. Réponses: 8
    Dernier message: 27/11/2009, 13h13
  3. [Livre]C++ Pour les programmeurs C
    Par progfou dans le forum C++
    Réponses: 1
    Dernier message: 31/03/2008, 20h42
  4. [Humour] les programmeurs et les blondes.
    Par souviron34 dans le forum La taverne du Club : Humour et divers
    Réponses: 12
    Dernier message: 05/03/2007, 10h52
  5. Réponses: 10
    Dernier message: 30/01/2007, 16h29

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