Discussion :

[RPGamer]

Ce que je veux dire c'est que pour un probl�me donn�, dans la majorit� des cas C offrira une meilleure solution en terme de performances, de memory footprint, etc. Le choix du C dans l'embarqu� n'est donc pas arbitraire.
De plus, toute la pr�sentation de Bartosz Szurgot est rendue caduc par un simple memset. Lorsque quelque chose semble sortir de l'ordinaire, un ing�nieur s�rieux commence par remettre en question ses r�sultats. Les scientifiques du CERN ont mis plusieurs mois avant de confirmer que leurs mesures correspondaient bien � un Boson de Higgs. Des mesures qui devaient prouver que les neutrino se d�placent plus vite que la vitesse de la lumi�re, ce qui d�passent les pr�dictions, avaient d� �tre invalid�es suite � la d�couverte d'une invarie.

[bacelar]

Bon, tout �a ressemble � une discussion sur le sexe des anges.

A part les VLA, quel code C n'est pas aussi du code C++, m�me sale ?

Et sauf erreur de ma part, c'est pas les VLA qui ont le secret de la performance du C via � vis du C++.

"memset" est aussi bien utilisable en C++ quand C, et c'est le m�me code machine.

Le niveau de customisation des compilateurs actuels permet de g�rer la totalit� des aspects donc mimiquer un compilateur C si celui-ci a une astuce magique.

Donc C n'est pas plus performant intrins�quement que C++, mais l'utilisation de fonctionnalit�s sp�cifiques du C++ peuvent avoir un coup.

Mais si le code optimal pour faire une t�che n'utilise pas de fonctionnalit� du C++, cela ne fait pas du C++ un langage moins rapide, car le code sera aussi compilable en C++ avec les m�mes performances.

[mintho carmo]

C'est quand meme tres reducteur de penser "C++ = utilisation de for, C = utilisation de memset". L'utilisation des fonctions heritees du C (voire des fonctions systeme) n'est pas interdite en C++ "moderne". Elles doivent juste etre utilisee uniquement quand c'est necessaire.

As tu vu les presentation de Dan Saks ? Dans l'une d'elle, il montre justement un fonction qui encapsule memcpy, ce qui permet d'avoir les avantages du type checking au compile time du C++ avec les performances de memcpy.

Je crois comme Luc qu'il y a un probleme d'aprioris, surtout quand on voit les benchmarks que tu cites pour justifier les performances du C vs le C++, alors que l'on voit en quelques secondes qu'ils ne mesurent pas la meme chose (comme beaucoup de benchmarks en fait...)

[RPGamer]

C'est quand meme tres reducteur de penser "C++ = utilisation de for, C = utilisation de memset".

A aucun moment cette affirmation a �t� faite.

L'utilisation des fonctions heritees du C (voire des fonctions systeme) n'est pas interdite en C++ "moderne". Elles doivent juste etre utilisee uniquement quand c'est necessaire.

C n'est pas C++. Si du code C peut �tre utilis� dans du code C++, �a reste du code C.

Je crois comme Luc qu'il y a un probleme d'aprioris, surtout quand on voit les benchmarks que tu cites pour justifier les performances du C vs le C++, alors que l'on voit en quelques secondes qu'ils ne mesurent pas la meme chose (comme beaucoup de benchmarks en fait...)

Comme je le disais, chaque langage a sa solution. On cherche la meilleure solution. Il ne s'agit pas d'un a priori, c'est ce que je fais par exp�rience et ce que fait toute la branche. Penser que personne ne connait C++ dans la branche est vraiment r�ducteur pour le coup. Il existe du reste un certains nombres de litt�rature et de cours sur les moyens d'optimiser du code pour l'embarqu� ou simplement pour diminuer les coups de grandes infrastructures en utilisant le langage C. Par exemple je connais un sp�cialiste en performances qui peut d�montrer qu'un datacenter est capables de diminuer sensiblement sa consommation d��nergie uniquement par des optimisation soft, optimisations r�alis�es via du code en C. Certe les autres langages �voluent mais il reste encore beaucoup de chemin � parcourir.

[mintho carmo]

A aucun moment cette affirmation a �t� faite.

Oui, mais tu le sous-entends, lorsque tu dis que remplacer for par memset en C permet de gagner en taille et en performances, comme si cela n'etait pas possible en C++.

C n'est pas C++. Si du code C peut �tre ex�cut� dans du code C++, �a reste du code C.

memset est dans le C et le C++. Utiliser un memset en C++ n'en fait pas un code C.
Au contraire, faire du type checking compile time, de la surcharge de fonction, des template, etc. fera qu'un code est du C++ et pas du C.

EDIT :
Et je crois que lorsque l'on parle de complexite du C vs C++, une partie de l'incomprehension vient de la.

En C, la syntaxe est moins riche qu'en C++. Comprendre un code "moyen" C necessitera generalement de connaitre moins de concept qu'un code "moyen" en C++. (Et ca sera encore pire avec des langages plus haut niveau comme le Java, C# ou Python, qui ont des libs standards tres riches et donc beaucoup plus de fonctionnalites a connaitre).

Mais la simplicite du langage C (et du C++ vs les langages plus haut niveau) demandera plus de travail de la part du dev pour faire la meme chose (un exemple classique est la manipulation de chaines de caracteres en C et en C++).

Au final, on echange une simplicite de syntaxe par un code plus important (et donc plus complexe). Quand on compare le C avec des langages haut niveau (Java, etc), la consequence est que l'on perd aussi le controle sur "ce qui se passe en interne".
Avec le C vs C++, cette comparaison n'est plus forcement pertinente, puisque le C++ offre le meme niveau de controle de ce qui se passe en interne, mais egalement la possibilite de faire du haut niveau (meta prog) avec un surcout minimal (voire aucun, selon ce que l'on veut faire).

Comme je le disais, chaque langage a sa solution. On cherche la meilleure solution. Il ne s'agit pas d'un a priori, c'est ce que je fais par exp�rience et ce que fait toute la branche. Penser que personne ne connait C++ dans la branche est vraiment r�ducteur pour le coup.

Dans ce benchmark, on compare une approche ecrite dans un langage avec une autre approche dans un autre langage et on laisse penser que les differences observees viennent des langages et pas des approches choisies. Au mieux, c'est de l'incompetance, au pire un mensonge.

Et non, je ne pense pas que toute les devs qui font de l'embarques sont incompetents. Mais je crois qu'ils sont humains. Et quand on bosse depuis 40 ans avec le meme langage et les memes habitudes de programmation, il est difficile de remettre en question ce que l'on croit comme acquis.
Et ce n'est pas le propre de l'embarque. Tous les devs doivent faire face aux problemes d'evolution rapide de l'informatique vs l'evolution de ses propres connaissances.

[RPGamer]

Le code C++ utilise std::fill() et diff�rents algo de la STL. Le code C uniquement des boucles for. En rempla�ant une boucle for par un appel � memset, ce que ferait naturellement un programmeur C, on fait simplement basculer les r�sultat en faveur du C. Lorsque l'on compare un code en C et un code en C++, que �a soit dans la pr�sentation ou en benchmark, on cherche la meilleure approche que peut fournir le langage. Si la meilleure approche que peut fourni un code �crit en C est plus performante ou moins gourmande en m�moire, on la privil�giera. Souvent, lorsqu'on ne dispose que de quelques KB de RAM, on a pas le choix, le langage s'impose de lui-m�me.

Les sp�cialistes en performances ne se base pas sur des acquis. Ils r�alisent des mesures de performances en cherchant � augmenter ces derni�res par rapport au probl�me � traiter. Un exemple des possibilit�s exploit�es.

[mintho carmo]

Un dev C++ utilisera std::fill et laissera les devs qui ont ecrit std::fill faire ce qu'il y a de mieux (en particulier appeler memset si c'est le plus performant). Et ensuite il fera des benchs pour savoir quoi optimiser et remplacera un appel a std::fill par autre chose uniquement si cela a un resultat tangible selon ses objectifs.

Et je crois que le probleme est justement le "ce que ferait naturellement un programmeur C". Je m'en moque un peu que l'approche "naive" d'un dev C est plus performante que celle d'un dev C++. Ce qui m'interesse, c'est ce qui restera lorsque les 2 auront fait leur boulot d'optimisation.
Et pour le moment, les arguments me laissent penser que les optimisations faite en C seront utilisables en C++, alors que le type checking du C++ ne sera pas exploitable en C.

[JolyLoic]

Tout d�pend des besoins. Pour programmer un MCU dans l'aviation par exemple on choisira le C pour obtenir un ex�cutable plus l�ger, moins groumant en RAM, plus performant et surtout compl�tement pr�dictible dans un contexte critique car le C++ fait des choses derri�re le dos du programmeurs qui ne sont pas toujours souhaitables.

Il n'y a pas de bonne raison pour �a, sauf que les compilateurs C++ sont moins pr�sents, moins robustes et moins certifi�s que les compilateurs C. Mais �a n'emp�che pas des entreprises travaillant dans l'embarqu� d'utiliser du C++ sur des aspects safety-critical. On peut citer Lockheed Martin, qui a par exemple publi� des r�gles de codage en C++ (http://www.stroustrup.com/JSF-AV-rules.pdf), ou le Mars Rover qui contient � la fois de C et du C++ (et on aura du mal � me faire croire que ces machines ont de la m�moire et de l'�nergie � revendre...).

[RPGamer]

Un dev C++ utilisera std::fill et laissera les devs qui ont ecrit std::fill faire ce qu'il y a de mieux (en particulier appeler memset si c'est le plus performant). Et ensuite il fera des benchs pour savoir quoi optimiser et remplacera un appel a std::fill par autre chose uniquement si cela a un resultat tangible selon ses objectifs.

C'est exactement ce que je dis, on cherche la meilleure solution offerte par le langage (et ses outils). En l'occurence, cette approche n'as pas �t� faite en ce qui concerne les solutions offertes par les outils du C (� savoir l'utilisation triviale d'un appel � memset ici) et il est probable que la diff�rence de performance soit aussi imputable aux autres outils du C++ utilis�s dans son exemple. Si tu avais regard� 2 secondes le code C++ utilis�, tu verrais qu'il n'y a aucune boucle for et que C++ apporte bien des surco�ts importants (40% de diff�rence quand m�me, je ne serais pas pr�t � payer ce co�t dans un projet) malgr� l'utilisation de std::fill() et std::accumulate() qui seraient capable d'optimisations magiques selon les a prioris. Les abstractions offertes par les langages OO sont certes tr�s utiles dans un certain nombre de situations mais en r�alit� elles induisent indubitablement des overheads lorsque la question des ressources disponibles et des performances se pose. Si cet aspect n'est pas trait�, les conclusions d'une pr�sentation comme celle de Bartosz Szurgot deviennent biais�es. A l'inverse, les benchmarks propos�s par benchmarks game fournissent les versions optimis�es des langages compar�s et certains algo impl�ment�s en C++ sont m�me plus rapides. Mais l�immense majorit� des cas d�montrent que C est plus adapt� en terme de performances (m�me le cas qui semblait d�montrer l'inverse sur lequel se base la pr�sentation). Comparer deux versions strictement identiques simplement en disant que l'une est en C parce que compil�e avec GCC et l'autre en C++parce que compil�e avec G++ n'a simplement aucun sens, �a reste du C qu'on le veuille ou non.

Il n'y a pas de bonne raison pour �a, sauf que les compilateurs C++ sont moins pr�sents, moins robustes et moins certifi�s que les compilateurs C.

Se sont d'excellentes raisons que j'ai �voqu� aussi. L'absence de possibilit�s de certifier et de prouver les compilateurs C++ (justement parce qu'ils font trop de choses cach�es que le programmeur ne contr�le pas) les rends �galement pour l'heure d�j� hors jeu pour un bon nombre d'applications en embarqu�. J'ai des coll�gues/amis qui travaillent dans des domaines de haute criticit�, ce qui n'est pas mon cas, notamment pour le d�veloppement de syst�mes cam�ra des prochaines sondes d'exploration de la NASA ou dans les syst�me de mesure dans l'a�rospatial. On discute r�guli�rement des diff�rentes nouveaut�s en mati�re de technologies et celles offertes par les derni�res normes de C++ et ils les connaissent. Malgr� tout, les syst�mes sur lesquels ils travaillent restent bas�s sur des syst�mes �lectroniques de type militaire (un convertisseur A/D � 30� dans le civil passe � 8000� pour les normes militaires!) avec du code certifi�/prouv� et performant r�alisable uniquement en langage C. Vous seriez de plus �tonn� par l'aspect rudimentaire de certains composants.

Le type-checking du C++ ne joue aucun r�le pour ces applications. Un programme qui n'est pas prouv� selon les standards en vigueur dans la branche ne passe pas la rampe et aucun assistanat de compilateur ne jouera ce r�le, � fortiori si ce dernier n'est pas certifiable. Les gens v�ritablement dans l'embarqu� savent ce qu'ils font, surtout vu les sommes en jeu.

Le C++ reste effectivement utilis� dans le domaine de l'embarqu� car il y a souvent n�cessit� de r�aliser des programmes de tests, de d�monstration, des interfaces graphiques, etc. des applications peu critiques pour lesquelles C++ est bien venu.

Pour r�sum�, selon les applications, on souhaite en g�n�ral dans l'embarqu� :

• Pouvoir r�aliser du code certifiable en fonction des normes de la branche (spatial, industrie, grand public, etc.) ou de l'entreprise
• Pouvoir optimiser le code, c'est-�-dire avoir un contr�le complet sur le code machine produit (va en partie avec le premier point)
• Pouvoir r�aliser des ex�cutables de taille r�duite
• Pouvoir r�aliser des ex�cutables avec une empreinte m�moire faible
• Pouvoir r�aliser des ex�cutables performants dans leur t�che d�di�e
• Pouvoir r�aliser des ex�cutable capables de r�pondre aux contraintes temps-r�el

Le niveau de contrainte varie d'un domaine � l'autre. Dans quelques cas C++ est suffisant et offre des abstractions qui le rend plus int�ressant que C. Dans la plupart des cas, le C offre de meilleures performances, un meilleur profil ou simplement le seul profil disponible pour les besoins.

Le C reste aussi largement utilis� (et m�me de plus en plus) dans des domaines non-critiques, j'ai donn� l'exemple du kernel Linux, un gros projet, des biblioth�ques bas-niveau, des pilotes et de bons nombre d'outils modernes (Git, NGS, ZFS, etc.). Les d�veloppeurs de ces applications font le choix du C en connaissance de cause, faisons-leur confiance

[Aiekick]

Pour avoir subit l'inverse, je peux te garantir que C puis C++ c'est la combo maudite pour faire de la merde sans le savoir.

Arr�tez de pendre vos lunettes de vieux cons, comment pouvez-vous regretter l'utilisation syst�matique de pointeurs nus dans un langage � exception ?
Les smart pointeurs, c'est irrempla�able, jusqu'� trouver encore mieux.

La normalisation du C++ a une d�marche proche des framework progressifs, rendre simple les cas courants, faire en sorte que les cas courants couvre le plus de cas possible et faire en sorte que les cas rares et complexes soient
Et oui, la programmation g�n�rique (template simple), le code fonctionnel � base de lambda, la programmation parall�le ou concurrente sont des cas maintenant des plus courants ou en passe de l'�tre. Et que les normalisateurs me tracent une autoroute pour m'en servir le plus simplement du monde, je leur en suis profond�ment reconnaissant.

Moi, je ne maitrise pas le C++, m�me apr�s plus de 20ans d'utilisation, mais tant que j'arrive � faire ce que je veux et qu'en cherchant un peu je trouve de super trucs qui me simplifient la vie, biblioth�que ou nouvelles normes, je suis content.

Avoir l'illusion de maitriser un machin et bien plus d�vastatrice que de savoir qu'on ne sait rien.

D�sol� les gars, mais les seules personnes qui peuvent dire que le C++ est trop compliqu�, c'est les vrais d�butants, pas ceux qui se paluchent les intrinsics des compilateurs en assembleur x64 ou Itanium.

un poil violent ta r�ponse dit donc.
Ce qui m'interrese c'est l'optimisation memoire, j'essai de faire ce que je veut tout en etant lightweight au possible (memoire, cpu et disk). j�aurais peu �tre du expliqu� �a.
et dans ce cadre, je code en asm les fonctions utiles, j'alloue ma memoire en C quand c'est utile, et j'utilise le c++ pour le reste.

Apres si on veut coder comme "un gros lourdos" a la java ou la c# ou on a un ramasse miette qui fait ce qu'il veut quand il veut et dont on ce fou, parce que au fond c'est pas notre probl�me la gestion memoire.
ou en c++ avoir un code simple au prix de 1000 lib toutes moins opti les une que les autre pour garder notre code propre c'est autre chose.

j'ai aussi regr�tt� d'avoir decouvert la prog sur windows plutot que sous linux, le c++ sur avec borland et son framework plutot que vs et le sdk windows.

ps : "gors lourdos" repond a 'lunettes de vieux cons' de ta r�ponse

[M�dinoc]

C++ est ce qui permet de ne payer que pour ce qu'on utilise, tant en place m�moire qu'en vitesse.
Et le unique_ptr<> est l'une des fonctionnalit�s les moins ch�res et les plus utiles du C++: Un pointeur transf�rable, mais garanti n'avoir qu'un seul "propri�taire", et g�rant la d�sallocation automatiquement.

C'est le meilleur moyen d'�crire du code exception-safe, absolument indispensable.

[Bousk]

Ce qui m'interrese c'est l'optimisation memoire, j'essai de faire ce que je veut tout en etant lightweight au possible (memoire, cpu et disk). j�aurais peu �tre du expliqu� �a.

Mu� enfin, je connais personne de sens� qui n'essaye pas de limiter un peu chacun de ces aspects. M�me si "on s'en moque" du cpu ou de la ram, on va pas s'�clater � en utiliser plus que n�cessaire.

et dans ce cadre, je code en asm les fonctions utiles, j'alloue ma memoire en C quand c'est utile, et j'utilise le c++ pour le reste.

Et t'as une quelconque �tude, article ou quoi qui prouve que c'est bien/mieux ?
Par exemple, coder en assembleur certaines parties, � part pour montrer qu'on connait l'assembleur et qu'on fait du code non/dificilement portable, y'a un int�r�t pour les perfs ? Parce que bon on est en 2016 et les compilos sont d�sormais bien puissants hein.
De m�me, allouer la m�moire en C ? Parce que tu crois vraiment qu'un malloc fera mieux qu'un new ? Et quoi de mieux au juste ?

[AoCannaille]

De m�me, allouer la m�moire en C ? Parce que tu crois vraiment qu'un malloc fera mieux qu'un new ? Et quoi de mieux au juste ?

Il en fera moins, donc plus vite. Il n'appelle pas la pile de constructeur dont h�rite un objet. Les constructeurs impl�ment�s sont potentiellement utile, ceux "par d�faut" font juste un appel de fonction et un changement de contexte pour rien.

Enfin bon, mis � part cette seule exception; je ne vois rien d'autre, mais bon, je ne suis pas un sp�cialiste du fonctionnement profond de la m�moire en C ^^

[bacelar]

Les constructeurs impl�ment�s sont potentiellement utile, ceux "par d�faut" font juste un appel de fonction et un changement de contexte pour rien.

Quelle-est cette barri�re quantique qui emp�cherait le compilateur d'inliner correctement les constructeurs et pas les autres fonctions ????

Pouvez-vous donner une "preuve" de ce que vous avancez ???

Il en fera moins, donc plus vite. Il n'appelle pas la pile de constructeur dont h�rite un objet.

Comme en C++ on �vite de faire de l'h�ritage profond, car c'est beaucoup trop rigide, la pile va pas bien �tre grosse, s'il y en a une ( rapport � la barri�re anti inlining du dessus).

Mais bon, les concepteurs de compilateur pour l'embarqu� sont peut-�tre des Illuminati �recteurs de barri�re quantique.

[r0d]

D'autant plus que le C++ est de moins en moins orient� objet (see Wasn't C++ object oriented last time I checked?)

[Luc Hermitte]

Il en fera moins, donc plus vite. Il n'appelle pas la pile de constructeur dont h�rite un objet. Les constructeurs impl�ment�s sont potentiellement utile, ceux "par d�faut" font juste un appel de fonction et un changement de contexte pour rien.

Enfin bon, mis � part cette seule exception; je ne vois rien d'autre, mais bon, je ne suis pas un sp�cialiste du fonctionnement profond de la m�moire en C ^^

Tu compares des choux et des carottes.
Si tu as besoin de construire ton objet (histoire de positionner l'invariant "est dans un �tat utilisable"), alors il te faut le faire. New est donc �quivalent � malloc + construction
Si tu n'en a pas besoin (i.e. parce que l'objet est un POD -- je simplifie), alors new ne fera rien de plus qu'un malloc.

Bref, tu paies avec new la m�me chose que ce que tu dois payer avec malloc. Si maintenant tu t'amuses � d�-PODifier tes agr�gats de donn�es d�pourvues d'invariants pour le plaisir de faire semblant de faire de l'OO ... le prix inutile, c'est pas la faute de new.

S'il y a critique � faire, potentiellement, new pourrait appeler malloc de fa�on mal inlin�e et pas une tierce fonction interne sur laquelle malloc repose �galement. OK, on paierait quelques petits cycles de plus � chaque allocation dans une telle situation.

[RPGamer]

Par exemple, coder en assembleur certaines parties, � part pour montrer qu'on connait l'assembleur et qu'on fait du code non/dificilement portable, y'a un int�r�t pour les perfs ? Parce que bon on est en 2016 et les compilos sont d�sormais bien puissants hein.

De plus en plus d'affirmations bidons dans ce topic. Certe les compilateurs s'am�liorent mais on est encore loin des performances obtenues en code natif. Le code natif sert surtout pour l'ex�cution des intrinsics (genre SIMD) ou pour des instructions particuli�res r�alisables uniquement en assembleur mais aussi pour de l'optimisation de performances. Le kernel Linux en poss�de un certain nombre par exemple. Donc oui, on utilise encore de l'assembleur encore aujourd'hui et �a a de l'int�r�t. Mais pas s�r que �a soit justifi� dans ce cas je l'accorde. Mieux vaut savoir ce que l'on fait et conna�tre l'architecture que l'on programme, �a va de soit si on fait de l'assembleur.

Il en fera moins, donc plus vite. Il n'appelle pas la pile de constructeur dont h�rite un objet. Les constructeurs impl�ment�s sont potentiellement utile, ceux "par d�faut" font juste un appel de fonction et un changement de contexte pour rien.

Globalement, l'id�e d'utiliser des fonctions de la libc pour allouer la m�moire dans un programme C++ est une mauvaise id�e qui te m�nera dans un mur.

[bacelar]

Certe les compilateurs s'am�liorent mais on est encore loin des performances obtenues en code natif

Tu confondrais pas C++ et JAVA ?
Le code g�n�r� par un compilateur C++, c'est du natif.

Le code natif sert surtout pour l'ex�cution des intrinsics (genre SIMD)

Qu'est-ce qui l'interdit de la faire en C++ ???
On peut faire de l'asm inline dans du C++ aussi bien que dans du C.

Donc oui, on utilise encore de l'assembleur encore aujourd'hui et �a a de l'int�r�t.

�a a de l'int�r�t que dans les vieux compilateurs C ou C++ tout pourri qui ne permettent pas une customisation fine comme dans CLang.
Mais avec des outils modernes, il n'y a que l'ours au fond du couloir avec une barbe qui s'occupera de customiser le compilateur pour le besoin, les autres utiliseront justes les instructions qui vont bien pour avoir les bons intrinsics customis�.
�a serait pas un syndrome sur la r�invention perp�tuelle de la roue carr�e, ces intrinsics customes ?

Globalement, l'id�e d'utiliser des fonctions de la libc pour allouer la m�moire dans un programme C++ est une mauvaise id�e qui te m�nera dans un mur.

Comme le C et le C++ utilise la m�me lib, �galit�, balle au centre.

Mais tout comme en C, en C++, sous Linux ou sous Windows, rien ne vous emp�che d�acc�der aux appels syst�mes via l'interruption software qui va bien et donc ne pas utiliser le libC (bonjours la portabilit� de merde).

Bon, pour l'instant, j'ai absolument rien vu qui ne soit faisable qu'en C et pas en C++.
Cela ne prouve pas que C++ est plus "performant" que le C, mais vous ne prouvez pas que le C est plus "performant" que le C.

Donc � part montrer que les programmeurs C sont soit de tr�s mauvaise foi, soit qu'ils n'y connaissent pas grand-chose en C++, cette discussion ne montre en rien la sup�riorit� sur C sur le C++.

Moi, la seule chose qui n'est pas possible en C++ (officiellement en plus) mais en possible en C, c'est le VLA.
Et on est d'accord que le VLA, c'est juste du syntaxical sugar et que cela ne change rien aux "performances", non ?

Et en plus, le langage, putain, qu'est-ce qu'on s'en cogne. Avec pas mal d'astuce, on peut m�me faire un driver en C# qui g�n�rera un code natif qu'on pourra contr�ler au niveau de l'assembleur, juste en customisant la chaine de compilation.

[Pyramidev]

Moi, la seule chose qui n'est pas possible en C++ (officiellement en plus) mais en possible en C, c'est le VLA.
Et on est d'accord que le VLA, c'est juste du syntaxical sugar et que cela ne change rien aux "performances", non ?

Je ne suis pas d'accord.
Les VLA (variable-length arrays) du C99 permettent, dans une fonction, d'allouer dans la pile un tableau dont la taille est inconnue � la compilation.
Par exemple, GCC alloue bien les VLA du C99 dans la pile.
C'est moins performant d'allouer dans le tas / la m�moire dynamique que d'allouer dans la pile, car malloc / new doit chercher quel emplacement m�moire allouer tandis que, dans la pile, il n'y a pas besoin de chercher : on alloue toujours au sommet de la pile.

N�anmoins, les VLA sont controvers�s. Plus d'infos ici :
http://stackoverflow.com/questions/1...th-arrays-in-c

[RPGamer]

Le code g�n�r� par un compilateur C++, c'est du natif.

Le code g�n�r� par un compilateur C++ est du code machine, bien vu

On peut faire de l'asm inline dans du C++ aussi bien que dans du C.

Encore une fois, faire de l'ASM dans du C, du C++, du D, etc. �a reste de l'ASM. Ca n�cessite de bien conna�tre l'architecture sur laquelle on travaille et �a permet de faire des optimisations plus pouss�es que les compilateurs m�me modernes ne peuvent pas faire et non, pas besoin de porter la barbe pour conna�tre l'architecture sur laquelle on bosse. J'ai pas envie de le r�p�ter sans cesse, quelques recherches sur les moyens d'optimiser du code en analysant le code machine (ou code natif) produit donneront des quantit�s de r�sultats (parmi celui que j'ai donn� provenant de chez Intel).

Comme le C et le C++ utilise la m�me lib, �galit�, balle au centre.

Premi�rement c'est faux, la libc =/= libc++ =/= libstdc++ et ensuite �a n'a rien � voir avec le sujet. Ici l'id�e �tait d'utiliser malloc() pour remplacer new, ce qui reste une mauvais id�e. Comme �a va dans le sens d'utiliser les outils de C++ plus adapt�s, un C++ enthusiast comme toi devrait le saluer.

Donc � part montrer que les programmeurs C sont soit de tr�s mauvaise foi, soit qu'ils n'y connaissent pas grand-chose en C++, cette discussion ne montre en rien la sup�riorit� sur C sur le C++.

Tu comprendras aussi que de la m�me fa�on cette discussion ne montre en rien la capacit� de C++ a faire de l'embarqu� comme en langage C. Mais je crois surtout que le sujet a bifurqu� sur autre chose entre temps.