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

Version imprimable

Voir 40 message(s) de cette discussion en une page

27/09/2016, 13h16
Coriolan

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

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

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

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

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

https://www.youtube.com/watch?v=D7Sd8A6_fYU

Source : YouTube

Et vous ?

:fleche: Qu'en pensez-vous ?

Voir aussi :

:fleche: La rubrique C++ : Forum C++, Cours et tutoriels C++, FAQ C++, ...
:fleche: CppCon 2016 : Bjarne Stroustrup parle de l'évolution de C++ et s'intéresse à son passé, à son présent mais aussi à son futur
27/09/2016, 14h04
jopopmk

Citation:

Envoyé par Coriolan

:fleche: Qu'en pensez-vous ?

Jamais ! JAMAIS ! AH AH AH AH !!! (je chauffe déjà et on est que mardi)

Bon ...
Perso, a priori je ne vois pas tellement d'avantage à passer au C++, toute la POO me semble assez aisément dispensable.
Par contre j'ai pas encore pu regarder la vidéo, je verrai ça quand j'aurai du temps devant moi (1h30 quand même).
27/09/2016, 14h19
foetus

Citation:

Envoyé par jopopmk

toute la POO me semble assez aisément dispensable.

Je mets 1 pièce que tu tapes à côté :mrgreen: :mrgreen:

Je pense plutôt qu'il insiste sur la RAII et sur le fait qu'en C++11 toutes les allocations dynamiques sont cachées: "code safer" ou un truc approchant :whistle:
27/09/2016, 14h46
jopopmk

Citation:

Envoyé par foetus

Je mets 1 pièce que tu tapes à côté :mrgreen: :mrgreen:

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

Je parle de mon cas : le seul intérêt serait d'avoir la facilité de conception qu'offre la POO, mais même là ça me motive pas.
J'espère effectivement qu'en 1h30 il a des arguments un peu plus chiadés que "la POO c'est trop d'la boulette" :lol:

PS : moi j'aime mes pointeurs pas safe et mes alias disséminés de partout :mrgreen:
27/09/2016, 17h07
ParseCoder

Le seul frein que je vois est la complexité du langage C++ et ça ne va pas en s’arrangeant. C'est clair que c'est plus complexe que le C et ça peut freiner une migration malgré les avantages du C++. Il faut tenir compte de la disponibilité des compétences en C++.
27/09/2016, 17h14
Pierre Louis Chevalier

Citation:

Envoyé par ParseCoder

Le seul frein que je vois est la complexité du langage C++ et ça ne va pas en s’arrangeant. C'est clair que c'est plus complexe que le C et ça peut freiner une migration malgré les avantages du C++. Il faut tenir compte de la disponibilité des compétences en C++.

Ça me fait penser à ce débat : C++ aujourd'hui est-il comme Fortran ? Aurait-il atteint ses limites ? Un ingénieur explique pourquoi il ne s'adonne plus beaucoup au C++ moderne
27/09/2016, 17h26
Luc Hermitte

On retrouve les présentations que Dan Saks avait données pour les Code::Dive 2015. Je reprends ce que je disais (il y a d'autres présentations pour le public qui doute des apports du C++ en embarqué) ici: http://www.developpez.net/forums/d32...r/#post8505022

Citation:

Envoyé par Luc Hermitte

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: https://www.youtube.com/watch?v=VEHh6jEavnc
- Representating Memory Mapped Devices as Objects: https://www.youtube.com/watch?v=Loac5nfK3XY

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.
27/09/2016, 17h26
derderder

Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ? Une vidéo pour inciter les pprogrammeurs C++ à passer au Rust me paraitrait plus utile...
27/09/2016, 17h44
Vincent PETIT

Citation:

[...]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.

Citation:

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.
27/09/2016, 18h17
Luc Hermitte

@Vincent, regarde la présentation de Bartosz Szurgot alors https://www.youtube.com/watch?v=PDSvjwJ2M80
27/09/2016, 19h15
Thorna

Tant qu'à choisir un truc un peu moderne qui a plus ou moins des airs de C, pourquoi pas plutôt D ?
27/09/2016, 20h14
Roadkiller

Citation:

Envoyé par Vincent PETIT

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

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

Citation:

Envoyé par Roadkiller

L'ignorance fait encore des ravages...

:D 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:

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

[...]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

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.

27/09/2016, 23h52
jopopmk

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

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

Citation:

Envoyé par Vincent PETIT

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

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

Si mes souvenirs sont bons, pas mal des exemples de Dan Saks concernent justement l'accès sécurisé à des registres. Son angle d'approche consiste à remplacer la détection d'erreur de manipulation/mélange de registres au runtime (phase de débugging profondément enracinée dans le mindset C-Embarqué selon lui), par une détection d'erreurs à la compilation, et ce tout en maintenant des performances identiques, voire des binaires strictement identiques.

Citation:

Envoyé par Vincent PETIT

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

Et si le compilateur n'avait pas été GCC ? Mais plutôt IAR ou Keil ou le compilateur propriétaire du fabricant ? Dans cette vidéo il n'y a pas vraiment d'exemple concret de la vraie plus value de C++ sur un micro.

La vidéo de Bartosz rapportait le contraire si mes souvenirs sont bons: des binaires et des vitesses identiques, voire plus courts d'un octet (sans qu'il sache pourquoi dans le cas du C++)

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

Citation:

Envoyé par Vincent PETIT

Pour faire entrer le C++ dans les systèmes embarqués il faudrait convaincre les 95% des développeurs électroniciens qui n'en n'ont malheureusement pas besoin.

On revient sur les videos de Dan Saks: "qui a besoin de quoi?" Comment passer de l'état d'esprit "je tape un truc, je compile, et enfin je commence à travailler i.e. le débugging commence" à "je corrige jusqu'à ce que cela compile et alors cela a de fortes chances d'êtres correct"? (Ce qui correspond à la boutade que j'ai souvent entendu pour Ada: "si ça compile, alors c'est correct")

Citation:

Envoyé par jopopmk

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

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

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

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

Ca me rappelle une autre conf récente au sujet des exceptions VS codes de retour: https://www.youtube.com/watch?v=0_FQIDEf7_Q Beaucoup sont persuadés que les exceptions sont plus lentes. Je suis intimement convaincu du contraire. Au départ, je me disais juste que l'on avait moins de branchements dans le cas nominal (OSEF de la vitesse en cas de situation anormale, hors embarqué) ce qui est mieux pour le pipeline, et j'ai découvert là, qu'en plus cela permettait de faire tenir plus de code nominal dans le cache d'instructions, ce qui est bon aussi. Les seuls bémols étant donc le binaire plus gros, et le surcoût titanesque en cas d'exception. Ce qui hors de l'embarque critique (avec vies en jeu) est complètement tolérable.
28/09/2016, 08h39
Uther

Citation:

Envoyé par jopopmk

Je parle de mon cas : le seul intérêt serait d'avoir la facilité de conception qu'offre la POO, mais même là ça me motive pas.
J'espère effectivement qu'en 1h30 il a des arguments un peu plus chiadés que "la POO c'est trop d'la boulette"

La POO par héritage est loin d'être le seul intérêt du C++, je dirais même que c'est certainement une des fonctionnalités les plus dispensables. Il y a énormément de choses intéressantes en C++ avec entre autre les templates, les smart pointer, la surcharge, ...

Citation:

Envoyé par derderder

Quel intérêt pour un programmeur C de passer au C++ plutôt qu'au Rust par exemple ? Une vidéo pour inciter les pprogrammeurs C++ à passer au Rust me paraitrait plus utile...

Il y en a déjà pas mal de videos qui présentent les bienfaits du Rust, mais on parle de présentation qui ont eu lieu à la CppCon. Ce n'est évidement pas l'endroit ou on va faire de la pub pour les autres langages, c'est de bonne guerre.

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

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

Citation:

Envoyé par Thorna

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

Le problème du D c'est qu'il n'est pas du tout adapté à l'embarqué à moins de désactiver toutes les fonctionnalités intéressantes, notamment à cause du GC. Il y a un effort en cours pour essayer de remédier à ça mais il est bien en dessous de ce que proposent C, Rust ou même C++.
28/09/2016, 10h52
transgohan

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.
28/09/2016, 11h20
CaptainDangeax

c++ pour quoi faire ?

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

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

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

Après, comme en C, il faut monter en compétence pour écrire du code optimisé. Il est normal que cela ne soit pas aussi efficace la première fois que l'on fait l'exercice tant que l'on n'a pas expérimenté les diverses nouvelles possibilités qui s'offrent à nous. Ils ont peut-être passé 5 fois plus de temps la première fois, je doute qu'il en aurait été de même les fois suivantes. Accessoirement, ils perdent des possibilités d'optimisation (cf pointeurs de fonction VS template, l'exemple typique qsort VS std::sort ; élimination sécurisée de la programmation défensive (fonctions qui testent toujours toutes leurs entrées, "parce que l'on ne sait jamais, le pointeur reçu pourrait être nul") ; ...)

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.

https://www.youtube.com/watch?v=zBkNBP00wJE

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

28/09/2016, 13h03
Matt_Houston

Citation:

Envoyé par Luc Hermitte

Le C++ présente l'intérêt de remplacer des heures de déboggages, ou d'écriture de test unitaires pour des babioles, par des baffes données par le compilateur. Il va râler bien avant sur nos bêtises.

Je ne sais pas trop à quoi tu fais référence ici. :weird: Je fais à la fois du C et du C++ et je n'ai jamais constaté de différences significatives dans le cycle de développement (enfin si, le C++ demande bien plus d'itérations à la conception, mais je mets ça sur le compte de mes compétences moindres dans ce langage).
28/09/2016, 13h07
Luc Hermitte

Je fais référence à l'argument avancé par Dan Saks: il profite du typage renforcé pour éliminer des erreurs d’inattention que le compilateur C ne peut pas trouver pour nous. Regarde la première video du fil de discussion pour plus de détails.
28/09/2016, 13h58
wolinn

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.
28/09/2016, 14h06
Roadkiller

Citation:

Envoyé par Vincent PETIT

:D Tu n'as jamais touché a un micro-contrôleur et ça se voit !

Oui bien sûr... J'ai fait tourner un robot à deux roues avec un asservissement en X/Y (angle/distance dessous et vitesse par roue dessus) à 10Hz, avec un A* d'un environnement de 3m*2m avec une granularité de l'ordre du centimètre, une représentation vectorielle de l'environnement et une IA pour décider et réaliser différentes actions (avec plusieurs actionneurs, décision et recherche de chemin sous les 500ms) sur un atmega128 (à 16MHz) et je n'ai jamais touché à un micro-contrôleur. Le tout en C++ avec l'utilisation des GPIO, timers et UART.

Après la dépendance vis à vis du compilo et des options de compilations, c'est déjà le cas en C en embarqué... Je ne nie pas le temps d’apprentissage nécessaire mais il y en a un de la même manière lorsque tu apprends le C pour la première fois.
Note : dans le cas du C++ embarqué, je parle uniquement du langage en tant que tel, je ne prends pas en compte la STL qui faudrait encore, de toute manière, en trouver des implémentations viables pour atmega et autres cortex-m.

Et si tu dois sérieusement te synchroniser à l'instruction près avec le cycle d'horloge d'un FPGA, tu oublies le C aussi... (à moins de compiler en -O0). Le C est déjà une abstraction, tu n'as aucune garantie que le code assembleur généré derrière sera bien ce que tu t'imagines que le compilateur sortira.

Bref, pas plus de temps pour faire une réponse complète, je retourne faire voler des Airbus (en C effectivement, décision imposée et gros historique).

Ps : le bout de code d'exemple de nikko34 est un bon début d'utilisation de template en embarqué mais on peut faire bien plus.
28/09/2016, 14h20
Luc Hermitte

Citation:

Envoyé par wolinn

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.

Intéressant. Ta remarque me parait être exactement dans la continuité de ce que raconte Dan Saks sur les cadres de pensée.

Je sais que je travaille mal et produit quantité d'erreurs d'inattention, et je suis persuadé de ne pas être le seul. Par contre, je ne m'en formalise pas -- peut-être parce que depuis longtemps je sais que j'ai besoin de relire 150 fois ce que j'écris en français et que de fait, aujourd'hui, j'utilise systématiquement le correcteur orthographique histoire de pouvoir me concentrer sur des choses plus intéressantes que des erreurs de typo.

En développement, c'est pareil. Je suis par exemple fâché avec l'appel à return pour renvoyer la dernière variable que j'ai calculée. Depuis, j'ai découvert une option de compilation pour me rappeler à l'ordre, et j'en abuse. On n'est pas toujours concentrés sur les petits détails. On va à la place penser à comment définir un traitement complexe avec trop de cas particuliers, à gagner des cycles ici et là, etc, et pas forcément au pointeur qui pourrait ou pas être légitimement nul en entrée de fonction. Ou encore, on ne sera pas forcément assez concentré pour remplacer tous les x par des y après un copier-coller.

Bref, tout ça pour dire que si je peux remplacer une erreur trouvable en débug, si on a de la chance, par une erreur de compilation, je prends!
28/09/2016, 15h03
CaptainDangeax

Coder proprement

Citation:

Envoyé par wolinn

Juste une petite remarque en passant : j'ai l'impression que tout le monde parait trouver normal de se reposer sur le compilateur pour signaler les erreurs.
Il est vrai qu'une compilation ne coûte plus rien, mais en ce qui me concerne, lorsque le compilateur me signale des erreurs, je considère que j'ai mal travaillé, trop vite, peu rigoureusement, je me demande s'il peut rester des erreurs que le compilateur n'a pas vues (ce qui est parfois le cas, c'est pour ça que je vérifie de temps en temps avec un autre compilateur).
C'est un peu comme si on était incapable d'écrire en français sans correcteur orthographique.

+1, Tout-à-fait d'accord avec ton approche. Que se soit en C ou en ASM, en bash ou en python, si j'ai des erreurs à la compilation, à l'assemblage ou au lancement, c'est que j'ai mal travaillé et je remets mon ouvrage sur le métier.
Autrement, le sujet du memcopy a été abordé. En ASM, il y a des optimisations possibles, comme le faire en décrémentant pour utiliser DJNZ (decrement and jump if not zero) et gagner une comparaison, ou le faire en parallèle ( 2 ou plusieurs copies par bouclage)... Des gourous du C ou du C++ sont-ils allé voir le code ASM généré par leurs compilateurs ?
28/09/2016, 15h12
Vincent PETIT

Citation:

Envoyé par Roadkiller

Oui bien sûr... J'ai fait tourner un robot à deux roues avec un asservissement en X/Y (angle/distance dessous et vitesse par roue dessus) à 10Hz, avec un A* d'un environnement de 3m*2m avec une granularité de l'ordre du centimètre, une représentation vectorielle de l'environnement et une IA pour décider et réaliser différentes actions (avec plusieurs actionneurs, décision et recherche de chemin sous les 500ms) sur un atmega128 (à 16MHz) et je n'ai jamais touché à un micro-contrôleur. Le tout en C++ avec l'utilisation des GPIO, timers et UART.

Je peux voir ton programme ?

ps : Je ne cherche pas la petite bête et lorsque je me trompe, je suis le premier à le reconnaître, cependant je demande a voir une preuve indéniable que le C++ est plus performant que le C surtout sur une cible comme un ATMEGA128.
28/09/2016, 15h22
Matt_Houston

Citation:

Envoyé par Luc Hermitte

Je fais référence à l'argument avancé par Dan Saks: il profite du typage renforcé pour éliminer des erreurs d’inattention que le compilateur C ne peut pas trouver pour nous. Regarde la première video du fil de discussion pour plus de détails.

Tu as un timestamp ? ;)

Les erreurs d'inattention que le compilateur C, puis valgrind, ne prennent pas en charge, il y en a tout de même très peu de nos jours. Le reste, j'aurais tendance à penser que c'est effectivement la faute à un manque de rigueur de la part de l'auteur du programme.

@CaptainDangeax, @wolinn, ça fait longtemps que vous développez ?

Mon intuition me souffle que c'est un état d'esprit propre à la jeunesse (avec mes 20ans d'expérience et plus -- je redécouvre sans cesse les joies de la compilation), vu que l'on tend à devenir plus pragmatiques et à accepter plus facilement les erreurs pour les avoir expérimentées à un moment ou un autre. Mais, je suis loin d'en être sûr. Est-ce une attitude juste humaine? Ou peut-être une conséquence de vos secteurs d'activité?

(En tout cas, c'est intéressant de voir que l'on peut avoir des visions très différentes -- et qui vont ensuite influencer nos goûts, nos choix, jusqu'à notre façon de travailler.)

Ce qui me fait penser qu'à l'opposé de vous, quand j'ai un truc un peut complexe qui compile du premier coup, je suis très sceptique et tends à me dire: "où s'est cachée l'erreur". (Ca c'est un sondage qui pourrait être intéressant)

Citation:

Envoyé par Matt_Houston

Tu as un timestamp ? ;)

Les erreurs d'inattention que le compilateur C, puis valgrind, ne prennent pas en charge, il y en a tout de même très peu de nos jours. Le reste, j'aurais tendance à penser que c'est effectivement la faute à un manque de rigueur de la part de l'auteur du programme.

Si mes souvenirs sont bons, cela redevient plus technique (et moins dans le cognitif) dans les 40-45 minutes. J'ai des exemples du même acabit dans la video de Bartosz (son avant dernier exemple je crois). On retrouve tous les types à la non_null qui fleurissent en C++ suite au CppCoreGuidelines ; types qui au fond ne sont que la transposition des types opaques de l'Ada. Il y a eu de la pub sur reddit pour un article sur ce sujet, bien que je trouve les exemples mal présentés: https://foonathan.github.io/blog/201...ing-types.html.

Typiquement, en C++ on peut écrire sans sur-coût sur les assembleurs générés par rapport au C:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 typedef TrucQuiVaBien<double> strictly_positive_number; double f(double x, strictly_positive_number y) { // pas besoin de tester si y est != 0, ou positif return x / sqrt(y); } ... double x = 42, y = entree_utilisateur(); // code qui ne compilera pas // -> MERCI le compilateur! C'est ce que l'on veut. f(x,y); // code où le développeur fait exprès d'ignorer l'erreur du compilateur // mais sans la corriger => il mérite des baffes! f(x, strictly_positive_number(y)); // code où le développeur fait son boulot: if (y <= 0) erreur.... else { f(x, strictly_positive_number(y)); } // Et bien sûr si on a un g qui prend un strictly_positive_number, ou qui sait en fabriquer un, // => on peut enchainer directement sans tests ; // pareil avec des boucles, on ne teste pas dans f(), mais à l'extérieur, donc il y a moyen de virer tous les tests. auto z = strictly_positive_number{ sqrt(1+abs(sin(y))) }; f(x,z);
Et avec ça on est conforme à la règle MISRA-C pour intercepter les divisions par zéros.
Après, je ne dis pas que cela ne soit pas un peu lourd à mettre à place. Des outils de preuve formelle pourraient être plus doués.

Le degré 0 de la technique, c'est l'emploi de références en place des pointeurs.

Après, oui valgrind (et autres sanitizers) peuvent intercepter beaucoup d'erreurs, mais si on peut les attraper avant (à la compilation), c'est encore mieux. On n'est alors pas dépendant d'un test qui pourrait ne pas couvrir des cas buggués qu'un compilateur aurait pu intercepter.

28/09/2016, 16h15
wolinn

Citation:

Envoyé par Luc Hermitte

@CaptainDangeax, @wolinn, ça fait longtemps que vous développez ?

Mon intuition me souffle que c'est un état d'esprit propre à la jeunesse (avec mes 20ans d'expérience et plus -- je redécouvre sans cesse les joies de la compilation), vu que l'on tend à devenir plus pragmatiques et à accepter plus facilement les erreurs pour les avoir expérimentées à un moment ou un autre. Mais, je suis loin d'en être sûr. Est-ce une attitude juste humaine? Ou peut-être une conséquence de vos secteurs d'activité?

(En tout cas, c'est intéressant de voir que l'on peut avoir des visions très différentes -- et qui vont ensuite influencer nos goûts, nos choix, jusqu'à notre façon de travailler.)

Ce qui me fait penser qu'à l'opposé de vous, quand j'ai un truc un peut complexe qui compile du premier coup, je suis très sceptique et tends à me dire: "où s'est cachée l'erreur". (Ca c'est un sondage qui pourrait être intéressant)

Ca fait 25 ans que je développe en C++...
Pour ce qui est de l'orthographe, je trouve horrible d'avoir besoin d'un correcteur orthographique pour écrire dans sa langue maternelle. En ce qui me concerne, j'écris quasiment sans faute du premier jet, sans y penser ni perdre de temps sur les détails justement, avec juste une ou deux relectures pour traquer des fautes résiduelles. Et ça me parait normal quand on s'exprime dans sa langue maternelle.
J'aimerais avoir ce niveau en programmation (en fait le retrouver), et je fais toujours des efforts pour y arriver, c'est à dire écrire naturellement sans erreur.
C'est un peu dur de se forcer à bien relire avant de compiler "juste pour voir", mais ça permet aussi au passage de détecter des vraies erreurs de logique que le compilateur ne peut pas voir.
Je pense que les programmeurs, moi compris, ont bien perdu en rigueur avec les langages de haut niveau et la compilation quasiment instantanée.
En fait, je faisais plus attention à l'époque où les compilations étaient coûteuses et les outils de débuggage plus rudimentaires, et j'essaye maintenant de corriger ces mauvaises habitudes prises au fil du temps.

Citation:

Envoyé par CaptainDangeax

Autrement, le sujet du memcopy a été abordé. En ASM, il y a des optimisations possibles, comme le faire en décrémentant pour utiliser DJNZ (decrement and jump if not zero) et gagner une comparaison, ou le faire en parallèle ( 2 ou plusieurs copies par bouclage)... Des gourous du C ou du C++ sont-ils allé voir le code ASM généré par leurs compilateurs ?

Petit test rapide :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #include <iostream> int main(int, char**) { unsigned const size = 1000000; double *a = new double[size]; // yep ça ressemble plus à du C qu'autre chose :) double *b = new double[size]; for (unsigned i = 0; i < size; ++i) { a[i] = (double)i; } memcpy(b, a, size * sizeof(double)); std::cout << b[42]; // empêcher la suppression du memcpy par optimisation return 0; }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ; memcpy(b, a, size * sizeof(double)); 00007FF6632F1050 lea rax,[rax+80h] 00007FF6632F1057 movups xmm0,xmmword ptr [rbx] 00007FF6632F105A lea rbx,[rbx+80h] 00007FF6632F1061 movups xmmword ptr [rax-80h],xmm0 00007FF6632F1065 movups xmm1,xmmword ptr [rbx-70h] 00007FF6632F1069 movups xmmword ptr [rax-70h],xmm1 00007FF6632F106D movups xmm0,xmmword ptr [rbx-60h] 00007FF6632F1071 movups xmmword ptr [rax-60h],xmm0 00007FF6632F1075 movups xmm1,xmmword ptr [rbx-50h] 00007FF6632F1079 movups xmmword ptr [rax-50h],xmm1 00007FF6632F107D movups xmm0,xmmword ptr [rbx-40h] 00007FF6632F1081 movups xmmword ptr [rax-40h],xmm0 00007FF6632F1085 movups xmm1,xmmword ptr [rbx-30h] 00007FF6632F1089 movups xmmword ptr [rax-30h],xmm1 00007FF6632F108D movups xmm0,xmmword ptr [rbx-20h] 00007FF6632F1091 movups xmmword ptr [rax-20h],xmm0 00007FF6632F1095 movups xmm1,xmmword ptr [rbx-10h] 00007FF6632F1099 movups xmmword ptr [rax-10h],xmm1 00007FF6632F109D sub rcx,1 00007FF6632F10A1 jne main+50h (07FF6632F1050h)
L'appel est inline, la boucle de copie à été déroulée / vectorisé correctement (128 octets copiés par itération), il n'y a pas de test inutile pour vérifier que les tableaux aient une taille multiple de 128 octets.
Il y a aussi 2 boucles "mélangées" travaillant sur deux registres différents pour faciliter la parallélisation de ces instructions par le CPU.
Il manque cependant l'optimisation sur la décrémentation / saut conditionnel; mais ya pas grand chose à redire du binaire généré.

De manière général les compilos font un bon boulot, il reste toujours possible d'aller trifouiller le code si besoin (que ce soit en C ou C++). :)

edit :

Citation:

Envoyé par wolinn

C'est un peu dur de se forcer à bien relire avant de compiler "juste pour voir", mais ça permet aussi au passage de détecter des vraies erreurs de logique que le compilateur ne peut pas voir.
Je pense que les programmeurs, moi compris, ont bien perdu en rigueur avec les langages de haut niveau et la compilation quasiment instantanée.
En fait, je faisais plus attention à l'époque où les compilations étaient coûteuses et les outils de débuggage plus rudimentaires, et j'essaye maintenant de corriger ces mauvaises habitudes prises au fil du temps.

Je vois ça un peu comme une perte de temps : si j’oublie un ";", le compilo le verra avant moi. Quand tout est si simple, pourquoi s'embêter ? (Mais effectivement, on perd en rigueur :/)
Pour les fautes de logique, c'est un peu pareil : un débogueur aide tellement que ça me semble être une perte de temps de relire x fois son code pour s'assurer que tout sera parfait lors de la première exécution.

29/09/2016, 09h32
foetus

Citation:

Envoyé par Iradrille

Je vois ça un peu comme une perte de temps : si j’oublie un ";", le compilo le verra avant moi. Quand tout est si simple, pourquoi s'embêter ? (Mais effectivement, on perd en rigueur :/)
Pour les fautes de logique, c'est un peu pareil : un débogueur aide tellement que ça me semble être une perte de temps de relire x fois son code pour s'assurer que tout sera parfait lors de la première exécution.

À vous lire, j'ai l'impression qu'on peut te faire la même réflexion :mrgreen: :mrgreen:: coder en C++ embarqué c'est un peu comme une perte de temps : parce que si à chaque fois il faut s'assurer que les "templates"/ "exceptions"/ capsules RAII/ ... fonctionnent et ne créent pas d'"overhead", bien il vaut mieux coder en C dont on est presque sûr de ce qu'il fait. Même si rien n'empêche de faire les mêmes vérifications en C.
29/09/2016, 09h48
Luc Hermitte

Il n'y a pas grand chose à s'assurer à chaque fois. Juste quelques tests à faire de temps en temps et un certain nombre de choses qui sont déjà connues:

- Si les capsules RAII provoquent des overheads, cela veut dire que le code en comparaison ne réalise aucune libération (je ne parle seulement de mémoire, mais de sockets, fichiers, locks, port, ...). Est-il bon? J'en doute. Et s'il n'y a rien à libérer, ben ... il n'y pas besoin de ces capsules.

- Pour les templates, entre un algo standard et une boucle faite à la main, il n'y a aucune différence si la boucle à la main est bien écrite. Voire, l'algo standard pourra être automatiquement remplacé en une des fonctions mem*(). Pour des conteneurs standards, il y a des techniques pour factoriser le code des fonctions les plus lourdes quand vraiment c'est intolérable.

- Pour les exceptions, il y a un overhead en taille de binaire, et un titanesque lors du déclenchement d'une exception. Ca, c'est connu. Par contre, là où il y a doute, et une absence de mesures sérieuses, c'est dans le cas nominal. J'ai posté une vidéo sur le sujet il y a quelques messages si mes souvenirs sont bons. Le truc est qu'un code correct en C devrait avoir un if toutes les 2 lignes pour remonter les cas de situations anormales. Cela implique branchements (avec prédictions plus ou moins heureuses), et moins de code nominal dans la mémoire cache pour le code. Avec les exceptions, le seul branchement qui reste, c'est celui du test qui va détecter le soucis (p.ex. message sur la socket ou le port série mal formaté). Ce qui veut dire que le cache pour le code ne contient que le code du chemin nominal -- ou pourquoi déclencher une exception coute un bras : il faut charger au dernier moment le code du traitement exceptionnel)
29/09/2016, 10h48
Riwalenn

Je trouve la courbe effrayante, je pensais que le C++ se bataillerait avec le C mais quenini :?. En BTS SIO on apprend le C++, quel intérêt si derrière les entreprises sont encore au C et refuse de passer en C++ ? Dans l'intention de l'imposer ? On impose rien à une entreprise surtout quand on est au bas de l'échelle. :roll:
29/09/2016, 11h06
Traroth2

(Disclaimer : je n'ai fait quasiment que du C et du C++ pendant mes études, mais ça date d'une époque où C++ ne gérait pas encore les exceptions. Et je n'en ai plus fait depuis ou presque et je n'ai suivi l'évolution des langages que de loin)

Je n'ai pas l'impression qu'on utilise le C et le C++ pour les mêmes choses. Le C reste indétrônable quand il s'agit de développer quelque chose de proche de la machine, pour l'embarqué, par exemple (mais pas que). Le C++, lui, n'est pas indétrônable du tout et les 15 dernières n'ont cessé de voir son champ d'application se réduire, en fait. Jusqu'à nos jours, où Rust et Go entament largement ce qui reste comme domaine de compétence pour C++. Mais le vrai problème de C++, aujourd'hui comme hier, c'est sur la manière exacte d'utiliser C++ que ça pèche. J'ai l'impression que la plupart des gens ont renoncé à utiliser C++ comme un langage objet (Comme disait Bertrand Meyer : "Quand nous avons imaginé les principes objet, nous ne pensions certainement pas à C++"), ce qui en fait une espèce de super-C aux fonctionnalités bizarres, mélange de haut niveau et de bas niveau, c'est à dire du haut niveau sans sécurité, permettant tous les hacks barbares. Ce qui ne fait pas de C++ un mauvais langage (pouvoir TOUJOURS trouver une solution peut être une bonne chose), mais simplement un langage à ne pas forcément mettre entre toutes les mains...

Ca peut paraitre de la provocation de dire ça sur un forum C++, mais l'article était en page principale. En tout cas, l'idée qu'il faille nécessairement migrer vers C++ si on fait du C me parait absurde.
29/09/2016, 11h15
foetus

Citation:

Envoyé par Traroth2

ce qui en fait une espèce de super-C aux fonctionnalités bizarres, mélange de haut niveau et de bas niveau

Justement tu te trompes :mrgreen: :mrgreen: Depuis le C++11, le C++ n'est plus du C (même si la compatibilité est assurée). Le métaprogrammation a pris le dessus.
Et c'est d'ailleurs pour cela que le C++ peut-être utilisé en embarqué: avec les "traits", SFINAE, et autres, le compilateur fait plein de tests et optimise le code "à ta place"

Regarde le code nikko34: c'est une orgie de "templates"
29/09/2016, 12h15
rt15

Citation:

Envoyé par Riwalenn

Je trouve la courbe effrayante, je pensais que le C++ se bataillerait avec le C mais quenini :?. En BTS SIO on apprend le C++, quel intérêt si derrière les entreprises sont encore au C et refuse de passer en C++ ? Dans l'intention de l'imposer ? On impose rien à une entreprise surtout quand on est au bas de l'échelle. :roll:

La courbe est valable pour les systèmes embarqués. D'une manière générale l'écart est beaucoup moindre.

Pour moi le gros problème du C++ est sa complexité (Qui est aussi sa principale force).
Complexité qui provient de sa polyvalence record et de son historique (Et donc entre autre de sa compatibilité avec le C).
D'accord on peut arriver à du code très simple avec le RAII et C++11, du code beaucoup plus court que le code C équivalent.
Mais bien souvent on arrive plutôt à des kilomètres de code et des modélisation peu banales, des erreurs de compilations illisibles et un débogage choquant.
Parmi les langages courants c'est le plus dur à "apprendre".
La création d'un compilateur C++ est monumentale par rapport à la création d'un compilateur C.
Le temps de compilation s'en ressent aussi.
L'ABI en C++ on va même pas en parler pendant que le C++ tout compilo, le .NET, le VB6, le Delphi et j'en passe attaquent des librairies dynamiques avec une interface "C" depuis des lustres.
Une bonne partie du code C++ écrit fin des années 90 début des années 2000 peut souvent aujourd'hui être considéré comme obsolète avec le C++ moderne. Il ne serait pas écrit de la même manière aujourd'hui. Le C n'a pas du tout la même philosophie et me semble beaucoup plus pérenne. Quoique plus vieux il vieillit moins vite. Il me paraît donc beaucoup plus réutilisable.

Bref le C est simple, performant et paradoxalement de mon point de vue mieux préparé pour l'avenir que le C++ pourtant moderne et qui évolue.
Il me semble moins en concurrence avec le C# et le Java que ne l'est le C++.
29/09/2016, 12h31
Tagashy

Enorme blague il fait l'ecole des clown le présentateur ^^
Rien que regarder la différence entre un hello world en c et en c++ au niveau asm ca suffit pour se rendre compte de la blague
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 .
pour les systemes enbarquer je suis bien d'accord le c++ n'as rien a y faire et pour les os "moderne" on se demande pourquoi le kernel linux est entièrement en C voyons faudrais moderniser en passer au c++ histoire de rigoler un peu.
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... ca peut etre utile pour une appli de compta et encore les languague haut niveau remplisse mieux le taf.
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???
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 ...
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, 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.
J'aurais encore plein de raison de choisir le C au C++ mais bon j'ai du taff qui m'attend donc pas le temps d'argumenter plus.
29/09/2016, 13h23
Ehonn

@Tagashy, ton message n'est pas vraiment techniquement correct.

Citation:

Envoyé par Tagashy

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

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

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

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

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

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

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

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

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.
29/09/2016, 13h32
wolinn

Citation:

Envoyé par Tagashy

...
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???
...

En CAO et simulation physique par exemple, c'est le standard industriel, au moins pour les projets récents, à côté des anciens codes en C et Fortran. Ca fait longtemps qu'on ne développe plus un modeleur géométrique en C, parce que pour ce type d'application, le C++ est vraiment intéressant.

Voir 40 message(s) de cette discussion en une page