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.