Discussion :

[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") ; ...)

[nikko34]

A la limite la conférence "un jeu pour C++17 sur Commodore 64", qui est en fait très semblable à ce qu'on ferait pour de l'embarqué (genre arduino), montre bien ce qu'on peut faire avec du C++ moderne bien plus puissant que du C.

Tout ce qu'il dit sur les registres etc je l'ai appliqué à un dev arduino donc non, le C++ apporte bien des choses pour l'embarqué (grâce aux constexpr, grâce aux templates, tout ce qui permet de pre-processer tout un tas de truc et rendre le code super lisible). Et faire des classes avec des méthodes, c'est souvent plus clair aussi, pour tout ce qui est concret (une classe Affichage LCD, une classe Timer, etc.. pas besoin d'héritage ni d'exception c'est sûr).

vous pouvez regarder ici: http://www.stroustrup.com/performanceTR.pdf section "Hardware addressing".

Ca permet d'avoir du code générique qui peut gérer plusieurs processeur par exemple. On peut écrire des choses comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[foetus]

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

[Matt_Houston]

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

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

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

[Matt_Houston]

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.

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

[rt15]

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.

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

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

[Ehonn]

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

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

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

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.

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

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

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.

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

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

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.

[wolinn]

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

[CodeurPlusPlus]

Non mais les vrais warriors codent en C et puis c'est tout.

[Lyons]

J'ai moi même fait la transition de C à C++ (je n'ai pas abandonné le C pour autant ) et honnêtement si c'était à refaire je ne le referais pas. C++ est syntaxiquement d'une complexité infinie par rapport aux langages modernes qui offrent les mêmes fonctionnalités et même avec un usage quasi quotidien je n'arrive pas à m'y faire. Je pense que ce fut une erreur de vouloir conserver aussi longtemps la rétrocompatibilité.
Sauf besoin impératif de compatibilité avec du code existant je ne pense pas que ça vaille la peine de se mettre maintenant au C++.

[nikko34]

A mon avis, le principal problème maintenant, c'est qu'il y a compatiblité avec le C et que le programmeur C refait du C au bout de quelques jours plutôt que de devoir chercher comme faire plus efficacement en C++.

Il faut aussi se poser la question de ce que l'on fait avec le langage. En C++ on ne fait pas la même chose sur un micro-controlleur que pour un GUI ou un process server. C'est assez ouvert et c'est peut-être ça qui est déroutant (mais c'est le but du langage).

Si le C++ est si complexe, que dire du Java ou même du Javascript? Ca doit vous paraitre des usines à gaz incompréhensibles.

[Uther]

Si le C++ est si complexe, que dire du Java ou même du Javascript? Ca doit vous paraitre des usines à gaz incompréhensibles.

Au contraire le langage Java en lui même est très simple par rapport au C++. Il a volontairement choisi de se débarrasser des aspect compliqués de C++. Après si tu compte les bibliothèques standard ça n'est pas comparable su que celle de Java est bien plus fournie.

JavaScript c'est assez différent. C'est a la base un beau bordel qu'on a essayer de spécifier a postériori.

[nikko34]

Pourquoi les generics en Java c'est simple et vector< string > en c++ ce serait compliqué?

Pourquoi se plonger dans la lib Java et pas dans la lib C++?

[foetus]

Pourquoi les generics en Java c'est simple et vector< string > en c++ ce serait compliqué?

Parce qu'il me semble que ce n'est pas la même chose

En C++, c'est du texte à trou, et c'est la compilateur qui va remplacer et ensuite te dire si "le contrat" n'est pas respecté.

En Java, le generic est vérifié à l'exécution. "disparaissent à l'exécution" me dit rt15

[mister3957]

Je développe en C++ pour de l'embarqué, avec un environnement de cross compilation pour générer les binaires dans l’architecture cible.

Une fois compilé, optimisé, transformé en instruction processeur, qu'est-ce que ça change si en amont ça a été fait en C ou en C++ ?