CppCon 2016 : Persuader les programmeurs de C de migrer vers C++
Par Dan Saks
Le 2016-09-27 13:16:59, par Coriolan, Expert éminent sénior
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
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 ?
Voir aussi :
-
BkteroModérateurLe 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.le 01/10/2016 à 22:43 -
Luc HermitteExpert éminent séniorOn 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
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.le 27/09/2016 à 17:26 -
RoadkillerMembre régulierL'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 !!!
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...le 27/09/2016 à 20:14 -
transgohanExpert éminentIl 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.le 28/09/2016 à 10:52 -
nikko34Membre éprouvé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..).le 30/09/2016 à 9:39 -
nikko34Membre éprouvé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 : 1
2
3
4
5typedef StateMachine< CDPlayer, // Current state | event | Next state | Action Transition< Stopped, play, Playing, StartPlayback >, Transition< Stopped, open_close, Open, OpenDrawer >, ...
le 30/09/2016 à 11:43 -
Vincent PETITModérateur
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 : 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.
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 :
Envoyé par Vincent PETIT
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.
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.le 27/09/2016 à 23:22 -
nikko34Membre éprouvé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 : 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();
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é...le 28/09/2016 à 12:51 -
EhonnMembre chevronné@Tagashy, ton message n'est pas vraiment techniquement correct.
Tu devrais retester
Pourquoi pas ?
(De plus système embarqué ne signifie pas toujours performances et temps réels (?))
GCC et Clang sont en C++.
Linux est en C principalement pour des questions de choix personnels.
Les templates ont été introduites avant C++14
C++ est un langage de haut niveau (qui laisse la possibilité de faire du bas niveau) (faut se mettre d'accord sur la définition avant tout débat).
La programmation générique et la métaprogrammation, ces deux aspects sont peu présents / assez pauvres dans le langage C.
Je ne crois pas que cela soit plus compliqué qu'en C (?)
Le RAII permet de ne pas oublier de libérer la mémoire (tout objet s'utilise comme un type de base).
Dans ce cas, il devra avoir un minimum de notions en C++.
Si un développeur n'a fait que du C, il risque de ne pas comprendre immédiatement le code source en C++ et ses subtilités.le 29/09/2016 à 13:23 -
BouskRédacteur/ModérateurAlors que pouvoir implements multiple est beaucoup plus simple
Tu peux très bien t'en moquer, tu es libre de plomber tes perfs.
J'en ai jamais eu besoin, peut-être rencontré 1 seule fois.
Hé oui, il faut savoir ce que l'on fait, personne pour balayer derrière toi
J'ignore de quoi tu parles, n'en ai donc jamais utilisé ni rencontré, ça a pas l'air bien important donc.
Longtemps il a existé tout un tas de libs pour le faire (pthread, TBB, Boost, ...)
Ne les utilise pas si tu sais pas y faire, c'est juste un truc super utile sinon
C'est vrai que devoir écrire une classe mytho pour avoir une fonction main m'a toujours paru bien plus intelligent
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
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/le 29/09/2016 à 18:48