Bon, j'avais commencé à écrire un message construit à @scalexm pour expliquer ce que j'avais pu lire à droite à gauche, mais entre temps il y a eu une avalanche de message, parfois prétentieux et pas pertinent (pas tous).
Je trouve dommage que personne ne puisse répondre à la question que ce pose @Nelimee et moi, je m'attendais à une ou 2 références expliquant en détail et avec de vrais arguments. Mais ce n'est pas le cas. Je trouve dommage que personne n'ait de réponses constructives, et j'ai donc fait des recherches par moi-même. Je ne détaillerais pas trop, car le débat semble clos pour beaucoup.
- La plupart des personnes et des tests disent/montrent que les 2 sont plus ou moins équivalent pour des programmes contenant le même code (un code souvent naïf), parfois l'un gagne parfois l'autre gagne. Cela dépend du matériel. Et de même pour des codes optis avec une large préférence pour le C++.
- parfois le C# out-performe le C++, la raison est généralement de code contre optimaux en C++, et les bons articles explique pourquoi le code C++ est mal écrit.
Pour le point 1, il montre bien que ce que dit @Nameless est faux, le C# n'est pas plus capable que le C++ de faire des optis local.
De plus il y a pas de code assembleur issus du C++ fonctionnant sur tous type de CPU, c'est les CPUs qui utilisent des Instructions Set identique pour simplifier la portabilité... donc les optimisations local dut au choix des instructions n'est pas un argument car le C++ fait donc la même chose (je soupçonne quand même la phrase d'être mal tourné car dans le cas contraire elle montrerait une forte méconnaissance du sujet. Si j'ai mal compris, autant pour moi).
Si il s'agit de dire qu'il a une meilleur organisation de la mémoire, qui peut être spécifique au système (utilisation des mémoires caches plus proche du CPU). Les résultats montrent bien que c'est pas toujours une réussite, et le C++ fait de même.
DrBrook
La simplicité et l'ingéniosité de la TPL (ainsi que de la programmation asynchrone en général), ainsi que le compilateur JIT permettront d'out-performances les bonobos qui développent en C++
Vous noterez l'insulte gratuite au passage.
Et @Nameless , tu ne réponds quand même pas la question, tu dit être un vrai dev, explique nous, on te demande.
Maintenant je vais essayer d'exprimer ce que je pense par rapport au message de @scalexm , qui propose une réponse par la thèorie.
Je suis d'accord pour dire que l'abstraction permet de résoudre les problèmes facilement, mais elle ne permet pas toujours de prendre le chemin le plus court (parfois elle le peut !). Et les structures abstraites permetent d'embarquer des optimisations, comme avec std::string.
Du coup je me sens obliger de te donner l'exemple, toujours en C VS c++, du printf et du std::cout.
Le printf est simple et bien optimisé.
Le std::cout est complexe car abstrait. (mais il permet plus de choses et il est quand même bien foutu)
Ce qui à pour effet d'avoir un std::cout beaucoup plus lent qu'un printf. Il en est de même pour tous les opérateurs de flux en C++ face au fonctions simple de manipulation de fichier en C.
Et c'est le genre d'erreur simple qui peut rendre un code C++ plus lent face à du C# si l'on fait une transcription direct de l'un à l'autre.
Je sait pas ce que tu en pense, mais pour ma part je trouve le sujet tres complexe et je ne peux pas me resoudre à dire: abstraction = perf.
Du coup, non il ne faut pas forcement un ingé avec 10ans de background ce genre de choses... Il le faudra pour concevoir un système qui utilise au mieux la machine et là on ne parle même plus de c# car on est de loin plus optimal.
De plus, je tiens à demander des excuses auprès de @w0dm4n qui trouve son poste concernant son projet pollué, j'imaginais que le débat serait intéressant. Mais peu semble prêt à cela.