IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Coriolan

64PARTAGES

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-nous-la !

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 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 Vincent PETIT
Modérateur https://www.developpez.com
Le 27/09/2016 à 23:22
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
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.
7  0 
Avatar de nikko34
Membre éprouvé https://www.developpez.com
Le 28/09/2016 à 12:51
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
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é...
7  0 
Avatar de Ehonn
Membre chevronné https://www.developpez.com
Le 29/09/2016 à 13:23
@Tagashy, ton message n'est pas vraiment techniquement correct.

Citation Envoyé par Tagashy Voir le message
La derniere fois que j'ai fait du c++ il me crachait des erreurs parcequ'il aime pas les pointeurs de fonction c'est sur que de son coter il y en as pas ... oups j'oubliais la vttable.
Tu devrais retester

Citation Envoyé par Tagashy Voir le message
pour les systemes enbarquer je suis bien d'accord le c++ n'as rien a y faire
Pourquoi pas ?
(De plus système embarqué ne signifie pas toujours performances et temps réels (?))

Citation Envoyé par Tagashy Voir le message
on se demande pourquoi le kernel linux est entièrement en C voyons faudrais moderniser en passer au c++ histoire de rigoler un peu.
GCC et Clang sont en C++.
Linux est en C principalement pour des questions de choix personnels.

Citation Envoyé par Tagashy Voir le message
Enfin bref le c++ c'est une usine a gaz qui commence a devenir une centrale nucléaire rien que la derniere norme avec les templates...
Les templates ont été introduites avant C++14

Citation Envoyé par Tagashy Voir le message
ca peut etre utile pour une appli de compta et encore les languague haut niveau remplisse mieux le taf.
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).

Citation Envoyé par Tagashy Voir le message
La seul utilite que j'y voie c'est pour les jeux video vu qu'ils on besoin de perf et d'OO a part ca il est utilisé dans quoi???
La programmation générique et la métaprogrammation, ces deux aspects sont peu présents / assez pauvres dans le langage C.

Citation Envoyé par Tagashy Voir le message
Le c a l'avantage d'etre proche de la machine on peut meme y integrer de l'asm facilement, le faire en c++ comment dire ...
Je ne crois pas que cela soit plus compliqué qu'en C (?)

Citation Envoyé par Tagashy Voir le message
pour le coter sécurité heum justement cacher les choses ne les rendra pas plus sécurisé ca donnera juste l'impression que ca l'est
Le RAII permet de ne pas oublier de libérer la mémoire (tout objet s'utilise comme un type de base).

Citation Envoyé par Tagashy Voir le message
par un contre un dev qui va te faire du c (et qui as de l'experience) comprendra ce qu'il se passe et saura ou ca peut planter et comment le corriger.
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.
7  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