chris, essaye de ne pas trop troller par ici. Gardes les pour le fofo linux ou le blabla eventuellement.

Il me semblait que mono etait un peu comme wine. Ca a toujours un wagon de retard sur la version courante. non ?

Ca va à une sacré vitesse :
http://www.mono-project.com/Roadmap

Ils implémentent déjà la version 3 du langage...
Faut pas oublier que c'est novell qui est derrière maintenant, donc ils ont bien plus de moyens qu'à leurs débuts.

Moi ça me semble gentiment viable en production à ce stade...

Il y a plusieurs chose. pour ce qui est du langage, mono a assez peu de retard donc n'est pas du tout handicapant. Le problème est plutôt pour le support des bibliothèque comme les winform où les différents contrôle que fournit MS. Là, oui, il y a pas mal de retard, mais certains diront que les implémenter n'est pas forcément le but de mono qui fournit la plateforme et pas le contenu (d'autre disent que si). Dans tout les cas, il est parfois possible de faire tourner les bibliothèque de MS sur mono pour régler ce problème (un peu comme le surclassage de bibliothèque de wine).

Par contre, comme le dit skip, le projet avance très vite car, contrairement à wine (et je dirais même à l'inverse de wine), ce projet est un exemple en matière d'ingénierie logiciel. Ils ont par exemple une batterie de tests monumentale avec des procédures très strictes ce qui fait que l'on ne voit jamais apparaître de régression pour le support de telle ou telle fonction (bien au contraire de wine une fois encore).

Bonjour, je m'invite à votre discussion.

Pour ma part, je travaille depuis peu sur C# (6mois) et je trouve que ce langage a d'énormes avantages quant à la rapidité de conception logiciel. Fini les gestions des Drag/drop de folie comme avec VC++, les fuites de mémoire, et j'en passe. Le Gros désavantage néanmoins reste sa lenteur d'exécution par rapport à des langages non managés.
Pour des phases critiques de calculs, j'ai de nombreuse fois du passer par une DLL car les temps étaient trop importants .(de 8 à 10s pour C# contre 500 à 700ms pour C++) Code presque identique.
C# est tres adapté a la conception visuelle. On retrouve d'ailleur avec l'integration de silverlight, ce que j'avais eu l'occasion de faire avec des application Flash/VC++. La puissance graphique de l'un avec les performances et l'ouverture matérielle de l'autre.

Quant a mono, l'exportation depuis un projet VStudio ou Sharpdevelop est assez simple. Quelques conventions néanmoins a respecter. Mais de ce que j'ai utilisé, les winforms restent assez bien gérées. Au delà de Linux, Mono etant aussi porté sous MAC. L'exportation vers les autres OS ouvre une voie interessante a C# et lui promet , je pense, un bel avenir.

"Pour des phases critiques de calculs, j'ai de nombreuse fois du passer par une DLL car les temps étaient trop importants .(de 8 à 10s pour C# contre 500 à 700ms pour C++) Code presque identique. "

Étonnant, sauf pour des choses très particulières, normalement tu n'a pas du tout une telle perte de perf. Est-ce que tu pourrait montrer du code C# et le code C++ équivalent sur lequel tu as eu ce genre de résultat ?

Sur un parser de Formule ... sur un tableau de 2000 points

code trop long pour être mis dans cette box

Pouir faire court, l'utilisation principale de ce parser est la manipulation de string (C#) / CString (VC++) de facon récursive pour interpreter chque caracter de la chaine et en evaluer la formule globale a partir d'un talbeau de valeur deja donné.

exemple : "(1.414 * sin(2*PI*T)* [f1(x)] + [f2(x)] )* PasseBas50Hz()";

f1(x) et f2(x) sont 2 tableaux de 2000pts chacun.

Dur à croire quand je vois que sur un algo de clustering sur 11'000 items (chose généralement réputée pour être très intensive), le passage d'un langage managé au C++, avec optimisation à outrance de l'allocation mémoire et une utilisation massive des templates m'a fait gagné environ 40% de vitesse d'exécution au prix d'une complexification très importante du code.

Il doit y avoir un truc qui coince sérieusement dans ta version C# pour que t'obtiennes des différences de cet ordre de grandeur.
Peut être que le type string n'était pas adapté à ce que tu faisais.

C'est bizarre effectivement. J'aurais été tenté de dire le compilateur JIT mais de toute façon, je possède "une grosse machine", je doute que cela vienne réellement de là. Sur certaines phases critiques (accès pilote USB) je suis descendu à 20ms contre 80ms en C#.

C# reste tout de même un excellent outils je n'en fait pas le procès, bien au contraire.

- Peut être que le type string n'était pas adapté à ce que tu faisais.-
C'est a dire ? vu que la chaine est rentrée manuellement. je n'ai pas trouvé d'autre solution.

Ben la compilation JIT te grille du temps sur la première passe, ensuite normalement ça devient rapide.
le problème du type string, c'est qu a chaque fois que tu fais une opération substr() ou que tu le passes à une fonction, il est réalloué.

mmm, des differences de cet ordre la, j'en voyait avec java il y a quelques annees et meme des bien plus mechantes (des problemes d'inlining, de type cast qui ont du disparaitre avec les generics dans java 5, des verification d'access aux tableaux superflue principalement). C'est sur que les compilateurs JIT ont bien evolue mais je ne sais pas si ils ont rattrape tout leur retard.

Non les generics de java sont implémentés en "type erasure" et sont perdus en compilation.
Donc casts et boxing à outrance sont encore de la partie. Par contre il existe des vraies collections de primitifs, la librairie open source du Cern en propose notamment.

Par contre l'inlining des fonctions marche très bien. Mais ces différences de x4 x10 traduisent souvent d'une mauvaise utilisation des classes à disposition, logique sans doute mais mauvaise néanmoins.

Comme _skip, je pense que tu devais faire une erreur sur la manipulation des string en C# et elles devaient être réallouées trop souvent, là où il n'aurait pas fallu (et où tu ne le faisait pas en C++).

KouicKouic
"Ce qui m'a le plus décu sur le C# (avis datant d'il y a 2 ans) c'est la lourdeur des interface graphique (ça a peut être changé maintenant) et surtout le fait qu'il ne soit pas vraiment portable, pas de support officiel de Mircosoft c'est vraiment pas cool."

-------

ça n'a pas vraiment changer, sauf avec le framework 3.5 et l'ajout de WPF.. là où les interfaces sont maintenant codé en XML (pas de compilation, yesss!) mais c'est pas vraiment du C#.. le code behind par contre est en C#

Pour la portabilité, il est portable sur tout les systèmes Windows où le framework .NET est installé.. c'est ça le but en fait! C# est un language "d'entreprise", dans le sens où tu peux monter un système complet avec .NET.. serveur microsoft, page web, app client-serveur, service web, etc... chose qui n'est pas possible avec java (il faut utiliser beaucoup d'outils différent)

par contre, c# n'est pas vraiment viable pour des applications grand publique (quoi que depuis vista, .NET est installé par défaut) donc à ce niveau, java et c++ clanche solidement mon ami préféré..

Autre point positif, c'est qu'il est 100% compatible avec des applic codé en vb.net.. et tout autre language .net! c'est magique je trouve.. une page ASP qui appel une DLL C# qui elle-même appel d'autre DLL en VB qui elles référence des services web.. absolument fantastique! côté réutilisation de code, on peut difficilement faire meilleur

Donc pour moi, C# (.NET en fait, peu importe le language) est plutôt destiné aux entreprises plutôt qu'au grand publique.. le développeur, chez lui, a plus ou moins intéret à utiliser ce language..

de plus, j'ajouterais qu'avec l'arrivé de Silverlight, WPF, XNA, et plus encore avec le framework 3.5, Java vient de se prendre une bonne claque sur la gueule!

j'ajouterais que niveau performance, on s'en fou un peu non? à moins que la performance soit limité sur le système pour lequel on développe une applic mais avec les PC qu'on a aujourd'hui, de réallouer une string ou pas, personne ne s'en rend compte..

on est plus à une instruction près de faire sauter la mémoire du PC!

Ouais mais ce genre de raisonnement abaisse la qualité générale du monde logiciel. Ce n'est pas parce qu'un programme n'est pas critique et que les PC sont puissants que c'est bien qu'il gaspille des ressources.
On en est pas au stade où il faut éviter de déclarer un int, mais savoir écrire des algos efficaces reste important.

"de réallouer une string ou pas, personne ne s'en rend compte.. "

Comme indiqué tout à l'heure, si. Évidemment, réallouer une seule string ça ne prend pas de temps. Mais quand, à cause d'un mauvais algo, ce n'est pas une, mais des centaines de milliard (par exemple) qui sont réalloué et transforme un algo linéaire en un algo exponentiel (au hasard) alors un programme qui devrait tourner un moins d'une seconde se mets à prendre 10 minutes pour tourner et là, tu t'en aperçoit. Donc non, il faut coder avec les bons algo. Mais ça, c'est indépendant du langage. Si le C# est un tout petit peu plus long pour allouer une string que le C++, alors là, oui on s'en fout.

" je pense que tu devais faire une erreur sur la manipulation des string en C# et elles devaient être réallouées trop souvent, là où il n'aurait pas fallu (et où tu ne le faisait pas en C++). "

Je me pencherai sur la question. en effet je fait des rolls sur la chaine (ce que je fais en C++). Peut-être qu'en faisant une approche différente. Genre convertir la string en char[] et travailler simplement sur le tableau. C'est vrai que vu que çà fonctionnais en C++ avec les CString je me suis pas plus posé la question que çà. Mauvais algo, ca doit etre ca.

Pour la mémoire, je suis d'accord avec _skip. Effectivement les PC actuels sont de plus en plus performants. Mais est on vraiment égaux sur le matériel ? Je travaille souvent avec CPUKiller pour voir globalement ce qui se passe sur des PC moins "équipé" et on se rend compte qu'une bonne gestion des ressources n'est pas négligeable.
C'est vrai que pour ma part je ne fais bien souvent que de l'affichage graphique. Mais même une application de SGBD. Attendre 10s pour récupérer le résultat d'une requête quand on pourrait ne mettre que 1 ou 2 s en optimisant le code ce n'est pas superflue.

c'est plus probablement un problème du aux type que tu utilise en C#. Fait attention de n'utiliser que des références et de ne jamais construire de nouvelles chaînes par hasard avec une copie implicite (là où une copie de référence suffirait). C'est probablement ce genre d'opération qui te pourri les performance. Mais, a priori, ça ne dépend de ce que tu travaille avec des chaînes ou des tableaux de char. Si tu fait la même erreur de copie sur un tableau de char, tu auras les même performances.