CppCon 2016 : Persuader les programmeurs de C de migrer vers C++ Par Dan Saks 55PARTAGES 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 Forum C++, Cours et tutoriels C++,

CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++ et s'intéresse à son passé, à son présent mais aussi à son futur 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 : YouTubeQu'en pensez-vous ?La rubrique C++ FAQ C++ , ... Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 122 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Modérateur https://www.developpez.com



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 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. Expert éminent sénior https://www.developpez.com 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:



Envoyé par Luc Hermitte Envoyé par 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: Tout d'abord les conférences de Dan Saks , un avocat de longue date pour employer le C++ en embarqué. Il y traite de, 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, 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 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 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. Membre régulier https://www.developpez.com Envoyé par Vincent PETIT Envoyé par 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.



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



Envoyé par Thorna Envoyé par Tant qu'à choisir un truc un peu moderne qui a plus ou moins des airs de C, pourquoi pas plutôt D



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 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 !!!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... Expert éminent https://www.developpez.com

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 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. Membre éprouvé https://www.developpez.com



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 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..). Membre éprouvé https://www.developpez.com



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 >, ... 8 0 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 :plutôt qu'à des if imbriqués à la toque. Modérateur https://www.developpez.com Envoyé par Roadkiller Envoyé par 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.



Envoyé par Roadkiller Envoyé par [...]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 !!!





Par contre !

Et c'est ça que je dis, d'ailleurs je me cite :

Envoyé par Vincent PETIT Envoyé par 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)





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++ !



Envoyé par Roadkiller Envoyé par 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





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 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 avantagesque 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)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.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 I2CLe 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 :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++ !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. Membre éprouvé https://www.developpez.com







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:



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();



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 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 :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é... Membre chevronné https://www.developpez.com



Envoyé par Tagashy Envoyé par 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.



Envoyé par Tagashy Envoyé par pour les systemes enbarquer je suis bien d'accord le c++ n'as rien a y faire

(De plus système embarqué ne signifie pas toujours performances et temps réels (?))



Envoyé par Tagashy Envoyé par on se demande pourquoi le kernel linux est entièrement en C voyons faudrais moderniser en passer au c++ histoire de rigoler un peu.

Linux est en C principalement pour des questions de choix personnels.



Envoyé par Tagashy Envoyé par 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...



Envoyé par Tagashy Envoyé par ca peut etre utile pour une appli de compta et encore les languague haut niveau remplisse mieux le taf.



Envoyé par Tagashy Envoyé par 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???



Envoyé par Tagashy Envoyé par 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 ...



Envoyé par Tagashy Envoyé par 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



Envoyé par Tagashy Envoyé par 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.

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 @Tagashy, ton message n'est pas vraiment techniquement correct.Tu devrais retesterPourquoi 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++14C++ 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. Rédacteur/Modérateur https://www.developpez.com Envoyé par rt15 Envoyé par Héritage multiple. implements multiple est beaucoup plus simple

Envoyé par rt15 Envoyé par Alignement des champs de structures.

Envoyé par rt15 Envoyé par Possibilité de faire de l'asm inline.

Envoyé par rt15 Envoyé par Pas de garbage collector.

Envoyé par rt15 Envoyé par Pas de caractères "magiques" UTF-32.

Envoyé par rt15 Envoyé par 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.

Envoyé par rt15 Envoyé par Surcharge des opérateurs.

Envoyé par rt15 Envoyé par Possibilité de faire du procédural, pas juste des fonctions statiques dans des classes.

Envoyé par rt15 Envoyé par Les pointeurs...

Envoyé par rt15 Envoyé par Les macros.



Sinon pour le troll JAVA vs C++ ça se passe ici 8 1 Alors que pouvoirmultiple est beaucoup plus simpleTu 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 toiJ'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 sinonC'est vrai que devoir écrire une classe mytho pour avoir une fonction main m'a toujours paru bien plus intelligentCf le garbage collector. J'imagine qu'il est plus simple de croire que tout est magie et laisser JAVA manipuler tout ça pour toiUn outil très pratique hérité du C à la baseSinon pour le troll JAVA vs C++ ça se passe ici http://www.developpez.net/forums/d18...t-cpp-vs-java/ Poster une réponse Signaler un problème

