Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[Langages] Le framework est-il réellement uniforme ?
bonjour,
suite a une discution que j'ai eu ont ma dit qu'il n'y a pas apres generation des fichiers executable de diférence entre VB C# et C++ .net, ca me parait
bizzard qu'il n'y est pas de diférence de puissance entre les ces derniers
,ont ma meme affirmé que c'étais ca le framework, alors pourquoi microsoft a fait 3 workspaces différents, et que vb .net serais aussi temps reel alors par déduction ?
cdlt Philo
Hello,
les langages .NET sont effectivement au pied d'égalité au niveau des performences (tant qu'on fait attention à les utiliser comme il faut). Ils produisent en effet tous un code quasiment similaire lors de la compilation en langage intermédiaire qui sera exécuté de la même manière par le runtime .NET. Il faut toutefois noter qu'il existe maintenant avec VisualStudio une version "native" du C++ et une version .NET. La version native n'est pas comparable aux langages .NET (C#, VB.net ...) puisque, par définition, elle n'a rien à voir avec la plateforme .NET. Les performences sont celles d'un C++ traditionnel, la bibliothèque standard aussi.
Bon week end
Bonjour,
par déduction c# serais un besoin créé par le marketing de microsoft,
cela semble plausible puisque c'est tres a la "mode" de créer les besoins,
en tout ca je pence avoir eu une bonne intuition de continer a travailler
sur le VC++ 6.0 qui lui est temps réel, j'ai pu le vérifier sur des projets.
domage que la platforme .net n'est pas temps réel ! cela engendre une grosse
faiblesse fasse a java .
quand au framework 3 avec winfx je sais rien du tous, si tu as des explications?
cdlt Philo
Je comprends rien du tout. C# marketing ? Temps réel ? Mais de quoi tu parles ?par déduction c# serais un besoin créé par le marketing de microsoft,
cela semble plausible puisque c'est tres a la "mode" de créer les besoins,
en tout ca je pence avoir eu une bonne intuition de continer a travailler
sur le VC++ 6.0 qui lui est temps réel, j'ai pu le vérifier sur des projets.
domage que la platforme .net n'est pas temps réel ! cela engendre une grosse
faiblesse fasse a java .
quand au framework 3 avec winfx je sais rien du tous, si tu as des explications?
Pour cet aspect, je crois qu'on peut admettre que Microsoft travaille à la promotion d'un langage qu'il a créé n'est-ce pasEnvoyé par Sphax
même si çà n'apporte pas grand chose au débat
VB6 aussi c'est un langage MS (et VB.Net) alors pourquoi parler de C# comme un truc marketing ?
Au vu des limitations artificielles introduites dans VB.net ou l'envirronement de dev de VB.Net on peut simplement dire que MS pousse plutot le C# au détriment du VB.Net.
Enfin bref de tte façon il me semble que philo71 confond un tas de choses et utilise des termes pas du tout adaptés ce qui indique un manque de connaissance et de compréhension de la plateforme. Malgré tout il en tire une conclusion étrange :
Bref si philo71 voulait bien donner qques explications sur ce qu'il entend par "temps réel" ça aiderait à comprendre....cela engendre une grosse
faiblesse fasse a java...
Smikar se trompe légèrement également dans sa réponse : il a toujours été possible de développer en C++ "natif" (ou "non managé") avec visual studio. Avec .Net on a vu apparaitre le C++/CLI qui permet de mélanger du code non managé avec du managé et qui nécessite donc le runtime .Net d'installé pour tourner.
Ce que veut dire Philo (je pense), c'est que puisque les langages .NET sont maintenant à égalité d'un point de vue perfs, la logique aurait plutôt voulue que Microsoft les unissent.
Au contraire, on voit apparaitre un nouveau langage, ce qui peut paraitre inutile d'un point de vue technique, et donc seulement une carte marketing.
Là où il y a méprise, c'est que C# apporte de réelles nouveautés. Il combine les atouts de C++ et de VB et fait bien plus encore.
La remarque sur Java semble indiquer que tu ne perçoit pas que Java fonctionne exactement de la même façon que .NET, c'est à dire s'executant dans une couche intermédiaire posée sur le système.
(désolé si j'ai trahi ta pensée)
En informatique industrielle, on parle d'un système temps réel lorsque ce système informatique contrôle (ou pilote) un procédé physique à une vitesse adaptée à l'évolution du procédé contrôlé.
On peut ainsi considérer qu'un système temps réel strict (hard) doit respecter des limites temporelles données même dans la pire des situations d'exécution possibles. En revanche un système temps réel souple(soft) doit respecter ses limites pour une moyenne de ses exécutions. On tolère un dépassement exceptionnel, qui sera peut-être rattrapé à l'exécution suivante.
cdlt
Philo
jobigoud:
C'est mal comprendre la plateforme .Net. Le seul vrai langage de cette plateforme c'est l'IL (Itermediate Langage) , cet espece d'assembleur de haut niveau que génère n'importe quel compilateur .Net (que ce soit celui de C# , VB, Python, Delphi etc...). Le but des langages de plus haut niveau étant de permettre à chaqun d'écrire du .Net dans son langage de choix, de maniere plus simple qu'avec de l'IL bien sur, ces langages pouvant qd même avoir de grosses différence de syntaxe ou non (on peut trés bien imaginer un langage .Net de haut niveau dans un style plus fonctionnelle et pas impératif par exemple). La plateforme permet ensuite d'utiliser les types générés à partir d'un langage dans du code d'un autre langage (voir d'en dériver, d'en faire ce que l'on veut). Aucun intérêt à n'avoir qu'un seul langage de haut niveau, pourquoi se limiter ?Ce que veut dire Philo (je pense), c'est que puisque les langages .NET sont maintenant à égalité d'un point de vue perfs, la logique aurait plutôt voulue que Microsoft les unissent.
Au contraire, on voit apparaitre un nouveau langage, ce qui peut paraitre inutile d'un point de vue technique, et donc seulement une carte marketing.
En ce qui conerne les différences de perf entre les langages .Net il peut y en avoir encore, ça viendra seulement d'une plus ou moins grande optimisation de l'IL généré par les différents compilateurs.
philo71:
Ah ben merci de m'avoir sorti la définition de temps réel , maintenant peux tu me dire quel est le rapport avec C#, .Net , C++, Java ?En informatique industrielle, on parle d'un système temps réel lorsque ce système informatique contrôle (ou pilote) un procédé physique à une vitesse adaptée à l'évolution du procédé contrôlé.
On peut ainsi considérer qu'un système temps réel strict (hard) doit respecter des limites temporelles données même dans la pire des situations d'exécution possibles. En revanche un système temps réel souple(soft) doit respecter ses limites pour une moyenne de ses exécutions. On tolère un dépassement exceptionnel, qui sera peut-être rattrapé à l'exécution suivante.
D'ailleurs (je ne suis pas un spécialiste, j'espere ne pas dire une betise) il me semble que pour faire du temps réel il faut avant tout un OS temps réel , pas un langage, donc vraiment je me demande ce que cette histoire de temps réel vient faire dans la discussion, si tu pouvais un peu organiser ton discours et l'argumenter.... Merci
en voyant la version 2005, je dirais que non. Même si j'ai pas regardé en profondeur C# 2, VB.Net 2005 est tres complet et rattrape le retard qu'il pouvait avoir sur C# dans le framework 1 et 1.1
la comunauté VB est trop grande pour mettre en retrait VB.Net de toutes façons
Effectivement ils ont rattrapé leurs "bourdes". Ma remarque s'appliquait plus à .net 1.1 et VS2003 , à ce moment la on pouvait bien penser que MS poussait plus C# que VB.Net (de manière artificielle je le répete encore). On peut aussi remarquer que la plupart des auteurs de blogs msdn font plutot du C# , un autre petit signe... Enfin bref C# VB.Net même combat c'est qu'une question de préférence et d'historique (VB.net pour les VB6 et C# pour les C++) , ce n'est pas le fond du sujeten voyant la version 2005, je dirais que non. Même si j'ai pas regardé en profondeur C# 2, VB.Net 2005 est tres complet et rattrape le retard qu'il pouvait avoir sur C# dans le framework 1 et 1.1
Je parle du temps réel car nous recherchons tous ça un traitement instantané, c'est vrai que je m'éloigne du sujet, mais pour quoi faire du c++.net si ont s'éloigne des spécifications de ce langage le c++!!
Il est vrai aussi que le temps réel s'applique aux os embarqués, mais voila ont peux spécifier un serveur haute disponibilité s'approchant du temps réel.
L'uniformité des langages dotnet >> ce qui me decoit !
Trois langages pour le même résultat. Le rapport entre c# et c++ du VisualStudio (et j'espère qu'un jour ils vont nous faire une version virtual studio) ben c'est surtout des temps de développements différents pour un résultat identique.
Pourquoi je parle de java, il est préférable de connaitre les produits concurrents surtout avec serveur d'application, et nota que Microsoft annonce 24% des parts du marché contre 21% de Java.
cdlt
Philo
le free store alias le tas
Bon décidemment je comprends rien a ton raisonnement et je ne vois pas du tout ou tu veux en venir. Je vais qd meme essayer de commenter tes propos.
Bon je pense que le temps réel n'a rien à faire dans la conversation, tu ne dois pas y connaitre grand chose (tout comme moi) et j'ai l'impression que tu utilises ce terme à la place de "performance".Je parle du temps réel car nous recherchons tous ça un traitement instantané
Le C++/CLI c'est simplement du C++ qui génère à la fois du code managé et non managé, pour pouvoir à la fois avoir accés aux pointeurs et aux objets .Net, réservé bien entendu à une utilisation bien particulière.c'est vrai que je m'éloigne du sujet, mais pour quoi faire du c++.net si ont s'éloigne des spécifications de ce langage le c++!!
Ta remarque n'a pas plus de sens que de dire : mais pourquoi faire du VB.Net puisque ce n'est plus comme le VB6...
Eu... oui, trois langages qui génèrent de l'IL (encore une fois le C++/CLI est un peu à part) , quel est le problème ? Tu choisis celui qui te convient et puis voilà. Je me repete mais .Net c'est plus que le C# ou le VB.Net ou C++/CLI , c'est avant tout le CLR et l'IL (voir mes commentaires plus haut). Vraiment là je ne comprends pas ce que tu repproches à .Net.L'uniformité des langages dotnet >> ce qui me decoit ! Trois langages pour le même résultat
Cette phrase est un mystère pour moi.Le rapport entre c# et c++ du VisualStudio (et j'espère qu'un jour ils vont nous faire une version virtual studio) ben c'est surtout des temps de développements différents pour un résultat identique.
Oui c'est bien de connaitre d'autres produits et langage, mais ça n'explique toujours pas ta remarque : "cela engendre une grossePourquoi je parle de java, il est préférable de connaitre les produits concurrents surtout avec serveur d'application, et nota que Microsoft annonce 24% des parts du marché contre 21% de Java.
faiblesse fasse a java ."
Bref à mon avis tu maitrises mal le sujet, tu devrais te documenter un peu sur .Net comprendre comment ça fonctionne, quel est le but. Dernier point : le code managé s'est montré sur de nombreux points aussi performant que le C++ (je parle de performance pure, temps de calcul de certains algo etc...) voir plus performant sur certains points. Ne parlons même pas des temps de développement bien plus courts en .Net qu'en C++ (et attention je suis un adepte du C++, seulement faut rendre à .Net ce qui lui appartient). Le seul endroit ou le C++ est indispensable c'est pour le développement bas niveau, ou bien si tu veux des choses portables vu que pour l'instant .Net ne tourne vraiment que sous windows.
Et même là les choses progressent peu à peu avec le projet Mono.
Ce qu'il veut dire c'est que les differents langages .net (a l'exception de C++/CLI) donne un resultat identique apres compilation (c'est le but non?) alors qu'en temps de developpement ca peut etre tres different selon ce qu'on a utilisé.
normalement non, encore une fois tout dépend plutôt de ce que propose le framework lui même en fonctionnalités natives ou si des implémentations supplémentaires sont necessaires (donc independemment du Langage)
ce n'est pas totalement vrai tu peux avoir acces a des features de la framework avec un langage et pas avec un autre, tu peux meme avoir des problemes d'interoperabilite entre deux langage de la framework si ils ne respectent pas les normes
Pour répondre à philo71,
.NET et Java : MEME COMBAT. Dans les deux cas, le code compilé, est un code intermédiaire en .NET du MSIL et pour Java, du JBC. Tes remarques sont donc totalement infondées. D'ailleurs à ce propos, détails technique qui devrait te faire réfléchir, mais le CLR de .NET a plus souvent recours à la génération de code natif pour executer le code IL que le runtime de java, beaucoup plus souvent. En fait, le runtime de java à un peu de mal a dissocier les sections critiques des sections non critiques et génére du code natif un peu à l'arrache et n'importe comment (malheureusement j'en ai fait les frais) en revanche, la CLR elle genere quasisystematiquement du code natif quand elle le peut pour accèlérer au mieux les traitement, la aussi j'ai pu voir la différence sur un projet personnel codé dans les deux plateformes, et les résultats sont éloquants. le code sous .NET sur un fichier de 30mo a mis environ 20% de temps en moins que le meme traitement codé en Java, de la meme façon.
Ensuite, la notion de temps réel, n'a strictement rien avoir le débat languages à compilation native, langages à compilation en code managé (IL/JBC...)
D'ailleurs cette notion n'intervient nul part dans aucun des débats que l'on pourrait traité ici, et d'ailleurs la seule autre notion qui pourrait s'en rapproché qui est le Multitasking qui ne concerne que le systeme d'exploitation et le hardware (capacité physique à faire du multiprocess ou non) et là encore, si le hardware ne le permet pas, on travail en notion de temps partagé, pour émuler le multitasking.
En ce qui concerne les performances, managé/natif, et bien là ... le probleme est le meme qu'avec Java, java est loin d'etre une référence dans le domaine de la performance à tout prix. et bien meme si .NET tire un peu mieux sont épingle du jeu, rien ne remplacera jamais un bon algorithme bien écrit en assembleur ou un algo bien écrit dans un langage plus évolué avec un compilateur capable de faire des optimisations de dingue (gcc par exemple)
Pour finir, je ne vois vraiment pas à quoi cela sert à de faire une polémique sur l'uniformité qu'apporte .NET vis à vis des différents langages disponibles, car en fait, après tout, tous les langages qui compiles un code natif, cherche a faire ce qui se fait de mieux en matiere de compilation, et souvent le résultat n'est si différent, surtout avec certains compilateurs comme gcc qui utilise 3 phases d'optimisations. De plus nombres de langages n'ont pas de compilateurs directs mais utilise simplement des transcrypteurs vers d'autres langages, au final le résultat est le meme donc ...
Maintenant c'est vrai , il ya quelques exceptions, VB6 par exemple n'est pas une référence de rapidité et de performances par rapport a une appli écrite en C++, là c'est vrai, mais bon, faut pas oublié que VB n'a jamais compilé de code réellement natif, il nécessitait toujours un tas de dll pour la plupart des runtimes.
L'uniformité est justement le saint graal du développeur, pas un inconvénient, l'interopérabilité parfaite entre langages c'est quelque chose de fondamentallement idéal. Si Microsoft n'a meme que partiellement réussi à faire celà, le but est louable, et je dirais qu'il faut les encourager à avancer dans cette voie.
Car tous les langages ont leurs points fort et leurs points faibles, et si tu choisi le langage pour ses spécifications propres et non pas parce que un tel et cencé généré un code plus rapide que un tel ... tu n'en est que gagnant.
Prenons un exemple simple, actuellement il existe deux méthodes de programmation, la méthode impérative, celle que tu connais avec tous ses langages comme C/C++, C# ... j'en passe et des meilleurs, yen a des milliers comme ca. Et une autre méthode, une méthode dite fonctionnelle qui elle reprend la formulation mathématique pour exprimer un programme.
Chaque méthode a ses points fort et ses point faibles.
Programmant en C++ ou en Ocaml, je peux t'assurer que développer une appli avec interface graphique en Ocaml, si littérallement l'angoisse, en revanche écrire un algo de tri style heapsort/quicksort en 5 lignes au lieux de 50, là je suis preneur, en plus la notation mathématique est particulièrement approprié pour ce qui est des traitements dans les graphes, ou des arbres.
Si tu met de coté les notions du fait que OCAML genere un code ultra optimisé en ce qui concerne la récursivité et qu'un algo quicksort généré par ocaml mettra certainement moins de temps à s'executer que son homologue C++, l'uniformité entre les langages permet donc de faire l'interface graphique en C++ et le moteur meme du programme ou ne seraitce qu'un fragment dans un langage fonctionnel nettement plus approprié et plus clair, et plus rapide.
Ma lib de gestion des graphs en ocaml a été écrite en 2h et fonctionne formidablement bien, l"équivalent en C++ m'a pris nettement plus de temps à écrire. Et personnellement vu que maintenant il existe un port de Caml pour .NET (projet open sur le net, non soutenu par microsoft) mélanger des sections en caml et des sections en C# ne me pose plus aucun probleme.
Maintenant je peux comprendre une certaine réticence vis à vis de .NET, tout au début, j'avoue avoir émis quelques doutes et réticences, et puis j'ai découvert C# ainsi que la véritable nature du framework et là ... je ne puis qu'applaudire Microsoft et les encourager dans le développement de cette plateforme.
PS : veuillez m'excuser pour les diverses fautes d'orthographes et autres, mais là je suis un peu fatigué ...
Répondre avec citation
Partager