CppCon 2016 : Persuader les programmeurs de C de migrer vers C++
Par Dan Saks

Le , par Coriolan

35PARTAGES

18  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Bktero
Modérateur https://www.developpez.com
Le 01/10/2016 à 22:43
Le plus triste dans cette discussion sont les réactions épidermiques des développeurs C en embarqué qui donnent tellement raison à Dan Saks.

L'embarqué, c'est mon métier. Plutôt du gros embarqué (Cortex M notamment). Pour paraphraser Vincent PETIT, ça tombe dans les 5% des gros projets mais sans doute ceux qui concentrent 95% des lignes de code de l'embarqué. Ben oui car dans 1k de flash on met pas beaucoup de code mais dans 1Mo il y a de quoi faire.

Il y a quelques années, je ne jurais que par le C. Je pensais le C++ fait pour de plus gros cibles, genre RPi, je ne parle même pas de Java. Et puis j'ai travaillé pendant 4 ans avec Java sur Cortex M. Et j'ai changé de regard. Des fois, on code en assembleur car on a besoin de tout maitriser. Des fois on code en C car veut encore maitriser mais veut être plus productif. Des fois on prend Java car on a moins besoin de maitriser mais on veut être très productif. Le bon outil au bon moment. Un tournevis c'est bien, une viseuse électrique ça peut servir.

Depuis peu, je découvre le C++ pour l'appliquer sur Renesas RX113. Et je pense qu'il y a des choses intéssantes à faire. J'ai déjà mis en place un framework de génération d'évènements à partir de boutons et de sliders physiques, grâce à des classes. Et c'est pratique, simple, adaptable. Pour la suite, je vais regarder du côté des templates ce qu'on peut faire d'intéressant.

Je suis un peu de triste de voir autant de gens fermés et des réponses se résumant à "C++ je connais pas, l'OO je connais pas, alors plutôt que d'être curieux, ben je dis que C++ ça sert à rien". C'est le métier d'ingénieur que d'explorer, de tester, de se former, de réssayer quelques années plus tard pour voir si les choses ont évolué. Et ici, j'ai vu beaucoup de commentaires à l'opposé d'une démarche positive.
16  1 
Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 27/09/2016 à 17:26
On retrouve les présentations que Dan Saks avait données pour les Code:ive 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.
12  0 
Avatar de Roadkiller
Membre régulier https://www.developpez.com
Le 27/09/2016 à 20:14
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...
12  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 28/09/2016 à 10:52
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.
9  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 30/09/2016 à 9:39
Après c'est peut-être moi mais vu le typage fort et les erreurs de compil, ça évite quand même d'écrire un paquet de test par rapport à des langages style "script" et ne nécesitte pas forcément un IDE poussé?

On dirait qu'effectivement pour certains avoir des erreurs des compilation est un drame apparement. Moi je dirais que c'est un avantage (encore plus en embarqué où les possibilités de debug sont faibles..).
9  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 29/09/2016 à 18:48
Citation Envoyé par rt15 Voir le message
Héritage multiple.
Alors que pouvoir implements multiple est beaucoup plus simple
Citation Envoyé par rt15 Voir le message
Alignement des champs de structures.
Tu peux très bien t'en moquer, tu es libre de plomber tes perfs.
Citation Envoyé par rt15 Voir le message
Possibilité de faire de l'asm inline.
J'en ai jamais eu besoin, peut-être rencontré 1 seule fois.
Citation Envoyé par rt15 Voir le message
Pas de garbage collector.
Hé oui, il faut savoir ce que l'on fait, personne pour balayer derrière toi
Citation Envoyé par rt15 Voir le message
Pas de caractères "magiques" UTF-32.
J'ignore de quoi tu parles, n'en ai donc jamais utilisé ni rencontré, ça a pas l'air bien important donc.
Citation Envoyé par rt15 Voir le message
Longtemps il a manqué des trucs de bases dans la librairie standard genre les threads. Il fallait traiter chaque OS. J'imagine qu'il en reste.
Longtemps il a existé tout un tas de libs pour le faire (pthread, TBB, Boost, ...)
Citation Envoyé par rt15 Voir le message
Surcharge des opérateurs.
Ne les utilise pas si tu sais pas y faire, c'est juste un truc super utile sinon
Citation Envoyé par rt15 Voir le message
Possibilité de faire du procédural, pas juste des fonctions statiques dans des classes.
C'est vrai que devoir écrire une classe mytho pour avoir une fonction main m'a toujours paru bien plus intelligent
Citation Envoyé par rt15 Voir le message
Les pointeurs...
Cf le garbage collector. J'imagine qu'il est plus simple de croire que tout est magie et laisser JAVA manipuler tout ça pour toi
Citation Envoyé par rt15 Voir le message
Les macros.
Un outil très pratique hérité du C à la base

Sinon pour le troll JAVA vs C++ ça se passe ici http://www.developpez.net/forums/d18...t-cpp-vs-java/
8  1 
Avatar de bacelar
Expert éminent sénior https://www.developpez.com
Le 29/09/2016 à 18:50
Héritage multiple.
Alignement des champs de structures.
Possibilité de faire de l'asm inline.
Pas de garbage collector.
Pas de caractères "magiques" UTF-32.
Longtemps il a manqué des trucs de bases dans la librairie standard genre les threads. Il fallait traiter chaque OS. J'imagine qu'il en reste.
Surcharge des opérateurs.
Possibilité de faire du procédural, pas juste des fonctions statiques dans des classes.
Les pointeurs...
Les macros.
Ce ne sont que des possibilités, dans un restaurant 3 étoiles, on ne prend pas tous les plats à la carte.
Et les "Pas de", c'est juste pas en standard, sinon, on trouve toujours notre bonheur avec des librairies supplémentaires.

Et avec JAVA 8 (fonctionnel, ...), tu vas péter un anévrisme.

P.S.: En plus, les trucs les plus cheloux (Les pointeurs, Les macros, ...), c'est à cause du C, donc comme argument pour interdire la migration/évaluation C vers C++, c'est assez moyen.
8  1 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 30/09/2016 à 11:43
Je sais toujours pas pourquoi vous voulez empiler les classes et faire de l'héritage à gogo en C++ sur micro-controleur.

Vous faites pas de struct en C? Ca ressemble pas à des classes avec des méthodes?

Dans mon code C++ embarqué on va avoir:

- une couche physique d'abstraction (à base de code pré-compilé, aucun overhead).
- des classes qui représentent mes composants physique
- pas d'héritage (pas besoin de polymorphisme dynamique..) plutôt du polymorphisme statique ( à base de template, sans overhead donc, déduit à la compil).
- des classes outils (ma petite bibliothèque) pour faciliter par exemple l'utilisation de flash string, de l'eeprom, la machine à état (entièrement en template).

Du coup par exemple, la machine à état va ressembler à ça :

Code : Sélectionner tout
1
2
3
4
5
typedef StateMachine< CDPlayer,
 //       Current state | event | Next state | Action
 Transition< Stopped, play,        Playing, StartPlayback >,
 Transition< Stopped, open_close,  Open,    OpenDrawer >,
 ...
plutôt qu'à des if imbriqués à la toque.
8  0 
Avatar de Firwen
Membre expérimenté https://www.developpez.com
Le 03/10/2016 à 8:59
Il existe aussi des personnes comme moi, qui ont beaucoup défendu C++ pendant des années, et puis qui en sont revenues et qui se sont remises au C.
C'est souvent ce que font les personnes qui n'ont jamais pris le temps d'apprendre le C++ correctement oui.
Quand tu as compris la puissance du langage, et ce qu'il apporte en terme de généricité, safety, efficacité.... Tu ne reviens pas en arrière.

La plupart des programmeurs C arguent que la première faiblesse du C++, c'est sa complexité. C'est faux, et c'est déjà prouver qu'ils ne comprennent pas le C++.

En C++, la notion reine est "Tu paies pour ce que tu utilises". Et c'est aussi valide pour la complexité.

Si les templates SFINAE, les variadics sont trop compliqués pour toi, rien ne t’empêche de te limiter à un subset du langage avec une complexité limité, tu y gagneras dèja beaucoup en terme de safety et d'efficacité ( lock object, unique_ptr, basic OO, STL type safe containers.... ).

C'est ce qu'un paquet de boites qui font de l'embarqué font, pour de trés bonne raison. Même google pour certains de ces projets se limite à un subset qu'ils définissent à l'avance.

Je pouvais parfaitement comprendre les critiques des programmeurs C vs C++, il y a 10 ans, principalement due aux faiblesses de la STL à ce moment là ( copies inutile dans std::vector, auto_ptr , abus des functors, etc ). Tout ça a été corrigé avec C++11 elles sont complétement irrélévantes depuis 2011.

Aujourd'hui quand je vois des personnes qui pondent des cathédrales en C, impossible à maintenir, bourrées d'overflow, et de memory leaks, et généralement plus lente qu'un equivalent en C++... juste pour l'unique raison qu'ils ont la flemme d'apprendre correctement un nouveau langage..... j'ai une forte envie de mettre des coups de boules.

Je vais troller un peu en disant ca, mais C apparait maintenant comme un subset dépassé de C++ qui a malheureusement loupé son évolution. Preuve s'il en faut avec C11.
8  4 
Avatar de Vincent PETIT
Modérateur https://www.developpez.com
Le 27/09/2016 à 17:44
[...]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.
7  3 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web