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

Citation:

---

Envoyé par Vincent PETIT

Tout comme moi qui ne voit pas en quoi il y a un avantage a passer au C++ (sur un microcontrôleur uniquement)

---

J'imagine qu'on peut faire des trucs sympas avec des sentries pour remplacer avantageusement les if/else ou goto :

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 28 29 30 31 32 33 34

struct DoSomethingOnExit { ~DoSomethingOnExit() { /* ... */ } };   void foo() { DoSomethingOnExit x; du code if(...) return; encore du code };   // vs void doSomethingOnExit() { ... }   void foo() { du code if(...) { doSomethingOnExit(); return; } encore du code doSomethingOnExit(); };   // ou void foo() { du code if(...) goto end_; encore du code end_: doSomethingOnExit(); };

---

Le code est plus robuste en C++ : tu ne peux pas oublier d'appeler doSomethingOnExit().
(Et le binaire généré sera identique à la version sans goto)

Il y a aussi l'argument d'avoir des erreurs de compilation

Code:

---

1 2 3 4 5 6 7 8 9

struct Second { ... }; struct Minute { ... };   void foo(Minute m); void bar(Second s);   Second s(1); foo(s); // erreur bar(s); // ok

---

Ce genre de chose générera un binaire strictement identique à la version C utilisant des int au lieu des Minute / Second. Mais tu auras une erreur de compilation quand tu fera une erreur d’inattention (= moins de temps perdu en debug).

En C++ on peut maintenant utiliser les user-defined literals, où on définit des unités pour les données et donc on vérifie à la compil que ce que l'on fait a du sens.

voir aussi cette présentation:

https://meetingcpp.com/tl_files/2013...ainerGrimm.pdf qui parle de ça et d'autres points pour l'embarqué.

Les commentaires en défaveur du c++ ne manque pas apparament...

Un bon professionel est bien souvent celui qui sait doser les efforts et utiliser les bon outils au bon moment. Comme un ebeniste n'utilise pas le rabo pour faire les finitions, mais la ponceuse, le dev embarqué n'utilisera pas necessairement le c++ pour programmer son micro-controlleur, mais le C (qui est utilisable aux cotés du C++, tout comme l'assembleur).

Bref, peut etre que pour faire progresser un domaine quel qu'il soit faut-t-il deja écouter les autres avant d'affirmer, dans ce cas regarder la vidéo.
Pour avoir fait partie d'equipes de R&D ayant mis sur le marché plusieurs produits qui marchent, je pense comme l'auteur de cette vidéo qu'aucune option n'est `a écarter, specialement quand on considere qu'un produit qui marche est un produit qui arrive sur le marché `a temps et que pour cela certains outils ou langages peuvent faire gagner pas mal de temps sur certaines taches.

Un exemple concret : quand plusieurs equipes travaillent ensembles une sur un framework qui lie un systeme embarqué `aun systeme d'info plus large, par exemple quand il y a un besoin de calcul sur differents coprocesseurs, qu'en gros on a autre chose qu'un petit programme tout seul dans son coin, C++ comme d'autre outils peut etre d'une grande aide pour aller vite et s'interfacer avec l'existant qui souvent n'est jamais qu'uniquement du C mais plein d'autres technos souvent plus facilement interfacable avec le C++ qu'avec le C. Enfin organiser une grosse base de code en C, c'est pas top et la POO apporte sans doute cela. Avant d'avoir un code optimise faut t il encore qu'il soit clair, maintenable et facile a comprendre.

Enfin sur le plan technique que sauf en desactivant toutes les optimisations, le compilateur optimisera en C comme en C++, et qu'a moins de bien tester le code, il y aura des suprises en C comme en C++ quand il s'agit de problématiques de temps réel etc. D'ailleurs c'est pas tellement le langage qui compte, mais l'OS, exemple : pour faire une mesure physique, une frequence, tension ou autre en temps reelil est evident qu'il faut utiliser un systeme temps reel, il est moins evident de dire que C++ ne fera que du code imprevisible a cause des pointeurs automatiques ou autres. C'est mal connaitre le langage que de dire des choses pareilles.