neross
Ce qui est totalement stupide en argument car byte[5] en C#, C+, Flash, Java ou autre tu auras toujour:s 5byte en mémoire ram. xP
http://www.abstractpath.com/2012/size-of-a-csharp-string/ si tu veux un simple example :p
Si je veux allouer une chaine de caractère j'alloue byte par byte dans un char*, toi tu prend déjà par défaut x bytes sans même mettre quoi que ce soit a l'intérieur, et j'pense que y'a plein d'autre example du style, quand ta une surcouche par dessus qui te fais un automatisme, t'en a forcément plus, après c'est vrai que maintenant c'est pas grand chose mais sur un émulateur a mon avis si
"Each .NET char takes 2 bytes." tu vois c'est pas si stupide que ça :)
Et tu prouve bien que tu sais pas trop ce que tu raconte, si on pars du principe de ton byte[]
En C++ ça pourrais donner un std::vector<char> qui lui meme de base est quelque part dans la mémoire et a une taille en plus des bytes que tu lui attribue, rien que de ça tu dois avoir beaucoup plus d'allocations du coté du .NET
scalexm
Ce que dit neross est tout à fait vrai. D'ailleurs l'empreinte mémoire supplémentaire utilisée par du code C# est vraiment négligeable par rapport au même code C++. Je ne sais pas ce qu'il en est à propos de Java par contre, mais j'imagine que ça ne doit pas être incroyablement plus élevé. Tu es sans doute habitué aux 1GB de RAM utilisés par Ancestra, c'est simplement parce que l'utilisation de la mémoire était extrêmement mal optimisée sur cet émulateur.
C'est vrai en théorie grâce aux performances réelles d'un langage relativement bas niveau comme C++. Mais en pratique, ce n'est pas du tout le cas, tu te rendras vite compte qu'il est extrêmement difficile d'écrire une grosse base de code en C++ qui soit à la fois maintenable et performante (dans le sens plus performante que la même base de code écrite dans un autre langage). La raison est que si tu veux réellement profiter des possibilités d'optimisation bas niveau offertes par le C++ qui apportent le gain de performance théorique, le code deviendra vite très difficile à maintenir, surtout que le gain en performances sera vraiment négligeable grâce à la puissance de nos machines d'aujourd'hui par rapport au temps passé à développer et maintenir. La question est très différente si on travaille sur de l'embarqué évidemment où potentiellement chaque cycle d'horloge compte, mais je rentre ça dans ce que j'ai appelé "applications critiques" dans mon post précédent.
Et je ne dis pas du tout ça parce que tu es en train d'apprendre: ce que je dis là, n'importe quel développeur C++ professionnel le constate sans arrêt (pour peu qu'il connaisse quelques autres langages quand même, histoire de pouvoir comparer). Si tu commences à écrire une très grosse base de code en C++, il y a peu de chances qu'elle outspeed violemment les implémentations dans d'autres langages. Et de façon générale, l'écriture du code est beaucoup moins productive en C++ qu'avec d'autres langages. C'est la raison pour laquelle il y a de moins en moins de nouvelles applications développées en C++ aujourd'hui. Même les gens qui développent des applications critiques sont en train d'essayer de progressivement remplacer le C++: par exemple le langage Rust développé par Mozilla (sur lequel je travaille actuellement d'ailleurs) a pour but d'écarter totalement la présence du C++ dans le moteur Web de Firefox. Le langage Go a été développé par Google dans la même optique: remplacer le C++.
Oui, ça prend plus de temps et tu fais plus facilement des conneries, je m'en suis déjà rendu compte que c'était relou t'inquiète x)
Le code difficile a tenir.. mmh non je suis pas d'accord pour ce genre d'application une fois que la base est faite tu n'y touche plus et rajoute que par dessus, mais oui ça prend plus de temps, pour avoir un bon exemple, ce que j'ai fais là en 1 mois peut-être ma pris 1/2 semaine en node.
Par contre oui c'est moin productif c'est sur
Mais une fois que tout le système est fait concrètement, ça devrait prendre le meme temps qu'avec un language lambda ^^