Reprise du message précédent :

yung3001 a écrit a écrit :     Oui mais de ce cas la, arrête de conduir, tu peux faire plein de conneries avec ta voiture, supprime les prises de courant chez toi , tu peux mettre les doigts dedans, ne fait pas de sport c'est dangereux... Si on se plaint des possibilités illimités d'un soft, y'a qu'a retourner sur Amstrad CPC, tu pouvais pas faire grand chose, et pas bcp de conneries avec le BASIC.

 
J'ai pas de bagnole et de toute manière vu comme les gens conduisent je suis pas pressé d'en avoir une.
Chez moi j'ai tellement peu de prises qu'elles sont toutes occupées donc pas de risques.
 
Et puis on va arréter de se prendre la tête sur un langage pouris. Je suis désolé mais quand on vois les réalisation précédentes de MS dans le domaine de la programation ça donne pas envie.
 
EDIT: Bon ok pour le pouris j'ai un poil exagéré, mais bon cette histoire d'intégratino de code assembleur dans un language interprété et à vocation multiplateforme (en tout cas pour ce que j'en ai entendu dire) ça me parrait être une faute conceptuelle.

 
Certe, faut te poser des questions si tu semble en avoir besoin; mais on en quoi est ce génant que cela soit possible ou pas? Tu veux programmer propre ou pas; tu peux faire de la merde avec n'importe quel langage, aussi bon soit il... tu es le seul maitre de ton code; donc non, cette possibilité ne me dérange pas, même si il n'est pas la bien venu dans 99.99% des cas.
 
Combien de programmeurs prennent le temps de commenter correctement leur code, de suivre convenablement des règles de nommage, de controler la validité des paramètres de chaque fonction en début de fonction, de penser 'objet' au lieu de penser 'couches' etc etc...

Juste pour fixer les idées :
 
1. je veux pas troller.
2. Si j'ai essayez C# au moins pendant 3 mois avant de jeter la chose out of the ring. Reaction allergique à MS ? peut etre ?
De toute maniére c de l'avis de chacun de choisir son lanage. Moi g choisi C++/Java/Delphi. point barre. slashdot na !
3. C bien bo de se lancer comme des oufs dans un nouveau langage bicos ceci cela ... amis bon les gars qqun a t il les %age de boites qui se sont dits : "oh Bob regarde Microsoft sort une nouvelle plateforme de dev. Si on jeter VS 6 et les 100000000000 lignes de codes qui vont avec pour nous foutrent au C# ? Oui bonne idée" laissons du temps au temps, on vera bien si dans 2 ou 3 ans on en parle encore.
 
4. personelmemnt je marcfhe a pied et je tripatouille mes prises electriques avec des chaussures isolants et un masque de soudeur (histoir d'avcoir le look). Naa je deconne. n'empeche que si on passez plus de temps à apprendre au gens a justement respectez le modele Objet, les conventions de nommages au lieu de leur changer de langage tt les 5 min ...
 
5. Allez bon point du VS .NEt : le deploiement des applications via XML.
 

 
ça, pour le temps, j'suis un peu d'accord...  

 
Ben, moi je suis pas pret de le lacher le c# ... Je fais que des prog pour windows et c tellement plus rapide que java (niveau création d'interface, fonctionnement de l'interface) et .... ca lui ressemble tellement.
 
Puis le XML c'est vraiment pas mal, jmen sers un peu et c sympa et clair.
 
Question : au passage, et vu qu'on sait jamais   , quelle est la classe Java qui lise/ecrive du XML ?

 
De toute façon, nous avons eu une equipe de développeurs dans notre boite qui a fait un projet tout en Java, et ça a été une vraie galère pour le débuggage, la maintenance et réussir à avoir des performances correctes. On n'a jamais eu ce genre de problème avec les outils de développement Microsoft; Il y a certain aspects qui ne sont pas encore parfaitement maitrisés dans ce language. Maintenant, faut voir ce que tout ce bazard de Java donne sous une plateform comme Solaris 9, le principal concurrent de .NET; j'ai des doutes...

je passe en coup de vent pour dire à ceux qui disent qu'ils n'arrivent à rien compiler sous .NET sont pas doués !
 
j'ai fait un prog de gestion d'élèves en C#, un prog d'extraction d'ID3 vers CSV en C++ MFC et un convertisseur de fichiers Unicode->Ascii en C++ console, et je n'ai jamais eu le moindre pépin...  

Harkonnen a écrit a écrit : je passe en coup de vent pour dire à ceux qui disent qu'ils n'arrivent à rien compiler sous .NET sont pas doués !   j'ai fait un prog de gestion d'élèves en C#, un prog d'extraction d'ID3 vers CSV en C++ MFC et un convertisseur de fichiers Unicode->Ascii en C++ console, et je n'ai jamais eu le moindre pépin...

 
A oui quand tu pars de zéro aucun problème; mais quand tu dois reprendre un source tout fait en Visual C++ de plusieurs milliers de lignes, c'est une autre histoire;
de plus as tu essayé tes programmes sous Win 9x, Windows NT4, 2000 ? tu risques d'avoirs des surprises aussi... enfin ça dépends de ce que tu utilises exactement...

Microsoft n'a jamais caché que le passage de VS 6 vers .NET n'était pas évident.

Aucune surprise, et j'ai testé sous 98, NT4 SP6, XP et 2000...

 
Remarque avec des programmes simplistes c'est normal!    
 
Sinon, t'as besoin qu'on te dise que t'es le meilleurs, non? T'es prof?  

yung3001 a écrit a écrit :     Remarque avec des programmes simplistes c'est normal!       Sinon, t'as besoin qu'on te dise que t'es le meilleurs, non? T'es prof?

 
nan pas prof, j'dirais plutot simplet
 
harko ->  

HappyHarry a écrit a écrit :     nan pas prof, j'dirais plutot simplet   harko ->

 
ça revient au même non?  

yung3001 a écrit a écrit :     ça revient au même non?

 
ah ben nan, c pas le meme nain  

HappyHarry a écrit a écrit :     ah ben nan, c pas le meme nain

 
Ah oui, y'en a un qui est de 'Gauche', et l'autre qui n'en sait rien...    

yung3001 a écrit a écrit : Sinon, t'as besoin qu'on te dise que t'es le meilleurs, non? T'es prof?

J'espere que tu ne plaisantais pas, car vu mon état actuel de dégout de la vie, j'ai pas envie de faire dans la dentelle. Si tu plaisantais, ne lis pas la suite de ce post, sinon, continue :
 
Cher ami, tu créé un post ou tu demandes un avis sur VS .NET, et tu termines en te foutant de ma gueule. J'ai lu les 1ers posts en biais, et j'ai répondu à la personne qui avait du mal à compiler.
Je commence à avoir une certaine expérience de .NET. Je l'ai utilisé au boulot, et j'ai appris le C# pour ma culture personnelle.
Je connais très peu Java, donc je me garderais bien de faire un comparatif C#-Java. Par contre, je peux faire un comparatif .NET-VS 6.0.
Je te le dis tout net () : VS 6.0 est mort et enterré ! Ceux qui prérerent cet environnement à .NET sont à mon sens des masos de 1ere ! Car, pour avoir travaillé longtemps avec VS 6.0, je peux t'assurer que je n'ai jamais vu un environnement aussi buggé. Par exemple, quand tu rajoutes une variable membre, ta classe disparait du ClassViewer, sympa... Il faut renommer le .h correspondant pour la récupérer !!
Et je te parle pas du compilateur : templates pourris, optimisations douteuses (j'ai eu la curiosité de désassembler un source compilé avec VC++ 6 une fois, et j'ai hurlé !!).
Quand j'ai essayé le .NET, j'ai immédiatement testé tout ce que je reprochais au 6.0 ! Et la, je suis resté sur le cul : tout a été corrigé, les optims sont bien plus efficaces, les MFC plus logiques (les CString sont maintenant des templates, c bien cool), les templates gérés correctement, etc...
Je ne parle pas du framework .NET, uniquement de l'environnement ! Je peux te dire que c le jour et la nuit avec le 6.0. Le framework souffre selon moi de grosses lacunes, ADO.NET en première ligne.
Quant à la possibilité d'ajouter de l'assembleur inline, je serais de l'avis de LetoII : pour un langage interprété, c absurde. Mais ce dont je suis sur, c que si MS ne l'avait pas implémenté, y'aurait tjs eu des mauvaises langues pour dire que .NET ne permet pas d'intégrer de l'asm. Et puis, personne n'est obligé de l'utiliser après tout...
 
Yung3001, sache que mes programmes simplistes, tu peux te les mettre
Au moins, j'ai pris la peine de tester .NET, en C#, MFC et console. Par conséquent, je suis bien placé pour donner mon avis. Si tu juges mes programmes trop simplistes, et bien montre moi les tiens, et s'ils dépotent tant que ça, et bien je m'inclinerais. Je connais un certain kayasax qui serait outré de lire ce que tu marques.... Quant à mon prog de gestion d'élèves en C#, tu peux sans doute le juger simpliste, toi qui me semble un grand gourou... Mais je doute fort que mon ex-copine pense comme toi (:cry ! Car la prof, ce n'est pas moi mais elle !! Et mon prog simpliste l'a délésté d'un bon paquet de fichier Excel !! Et moi, il m'a permis de voir le fonctionnement d'ADO .NET (pourri), ainsi que de controles comme le Datagrid (usine à gaz, puissant néanmoins !!!)
Je ne te demande pas de me féliciter, mais juste de me montrer les programmes que tu as pu réaliser qui t'ont permis de tester si profondément .NET....
 
HappyHarry >    

Je ne lis même pas la suite, je note tout simplement que le seul point de comparaison que tu utilises est universellement considéré comme une bouse, enterrée depuis longtemps. Donc c'est rassurant que ce soit mieux, mais ça ne donne pas de points de comparaison avec des environnements de développement modernes basés sur Python ou Java.

 
la n'est pas le but, l'objectif du topic, c t de comparer .NET a ses prédécesseurs chez crosoft  

Sacré double Jar, toujours aussi trolleur à ce que je vois
 
Je remercie HappyHarry de son intervention, car effectivement, Yung3001 demande bien une comparaison entre VS 6.0 et VS 7.0.
 
Au fait Yung 3001, ne me dis pas qu'avec ton expérience sur VC++ 6.0, tu es passé à coté du bug des classes qui disparaissent....  

Juste quelques petits trucs à propos de l'ASM, vu que c'est un truc que certains ont l'air de reprocher à .NET :
 
1) Pour un programme portable, y'a pas qu'au SDK de proposer un environnement portable. Il faut aussi réfléchir un peut, et se dire que l'ASM est un truc à oublier dans ce cas... Tout comme un certain nombre de classes... En java aussi, il y a des librairies qui sont assez dépendantes de la plateforme. Si on sait qu'on va utiliser son soft sur une autre plateforme, suffit de pas les utiliser.
 
2) Dans tout les cas, que le programme contienne de l'ASM ou non, y'a toujours la couche du runtime .NET qui va le contrôler. Alors selon comment le runtime d'Unix (ou autre) sera écrit, il pourra très bien interpréter l'ASM. En effet, l'avantage de l'ASM c'est d'être rapide. Mais à part ça, il n'apporte rien, pas même au BASIC. Rien de plus simple que de traduire à la volée l'ASM en langage évolué... MOV AX, BX ça devient "ax = bx;" (cool) Donc un prog contenant de l'ASM pourrait très bien être portable au moment de la sortie du SDK final sous Unix.
 
3) Le C# n'est pas là uniquement pour concurrencer Java. Il est là aussi pour faire évoluer le C++. Le C# est en effet une simple évolution du C++, comme ce dernier était une évolution du C. Il faut conserver un minimum de compatibilité ascendante, et je vois pas des gens qui se sont arrachés les cheveux pour optimiser des parties entières de leur code en ASM devoir réécrire des morceaux entier de leur code pour qu'il compile avec .NET, simplement parcequ'ils voulaient profiter de certaines évolutions du langage...
Toujours dans ce sens, le C# n'est pas seulement écrit pour être portable, mais bien pour remplacer à terme le C++, comme ce dernier à remplacé le C (même s'il y a toujours des devs en C). Donc il est assez bienvenu d'étendre un maximum les capacités du SDK, au risque de proposer des extensions non portables. Aujourd'hui, il faut savoir que la majorité des programmes écrits en Java sont écrit pour Unix, sans la moindre intention de passer sur un autre OS un jour, et essayer de faire tourner ces progs sur un PC ou un MAC est quelquechose d'impensable sans réécrire la moitiée du code.
 
Voilà. Ce post de la part de qq1 qui galère comme un russe avec le C# mais qui est tout de même assez content de la facilité de dev et de la puissance au final, et qui ne connait rien au java, mais qui a des feedbacks sur ce dernier tout les jours.

Troll !!!
Quand, à config équivalente, le C# interprété sera aussi rapide que du C++ compilé, on en reparlera !
 
Le C++ a remplacé le C (quoique...) car ce sont 2 langages compilés.

Troll toi-même.
 
Déjà, niveau langage interprété et leur implémentation, faut vraiment être développeur d'OS ou bidouilleur du dimanche pour encore venter les mérites du code pur C++ compilé.
 
Parceque quelques soient les environnements (UNIX, Mac, Windows) on a de plus en plus de langage de haut niveau (Buisiness Object par exemple, ou tout simplement le SQL) qui permettent de faire des choses en environnement dédié de façon plus épurée que se taper les 3 millions de lignes nécessaires à lire un champs dans une base.
 
Deplus, niveau montée en charge, que ce soit le PHP, le Java ou même m'ASP (qui pourtant est à la ramasse complète bien qu'en léger progrès), tous ont fait leurs preuves : pour des applications client/serveur, l'interprété s'avère aussi rapide, et dans certaines conditions, plus rapide que du compilé.
Simplement car tout ce qui est en rapport avec le multi-thread par exemple, ou réutilisation des objets en mémoire sera forcément mieu géré par un runtime avec garbage collector que le code compilé (ou alors tu t'es vraiment masturbé longtemps devant chaque ligne de ton code pour y arriver)
 
Deplus, les environnements Windows à venir, s'ils s'appellent ".NET", c'est pas par hasard. Ils intègrent en natif, au niveau du kernel les appels écrits avec le SDK .NET
 
Le code natif risquera d'ailleurs d'être désavantagé à l'avenir sur plateformes M$ car il ne sera plus supporté par le kernel (et donc une couche suplémentaire sera nécessaire pour traduire les communications entre le programme et le kernel). C'est notamment le cas pour le COM/DCOM. Il n'est plus supporté à bas niveau par Windows.NET. C'est le nouveau système d'interopérabilité utilisé par .NET qui est le système natif de cet OS.
 
Deplus, actuellement, les perfs de .NET sur un Win2K sont vraiment très bonnes (mise à part la première éxécution, juste après compilation/installation de l'exe)
 
Deplus, avec la diversité des matériels, et l'évolution extrêment rapide des machines, le compilé souffre d'un énorme problème :
 
-> Si tu veux tourner sur un PC non SSE, tu dois désactiver un tas de trucs dans ton compilo. Mais si tu veux que sur un SSE ça soit rapide quand même, faut encore adapter... Et quand sort une nouvelle norme d'instructions CPU, ton programme, faut rechercher la vieille disquette à moitiée effacée dans un carton, et recompiler le programme.
-> Le compilo optimise le code natif selon la configuration pour laquelle il est prévu. Notamment si tu indiques au compilo 32 Mo de RAM et 1 seul CPU, ton soft sera super mal supporté et pas optimisé du tout pour tourner sur un octo processeur avec 4 Go de RAM par CPU... Et l'inverse encore plus.
 
Avec un runtime, l'avantage c'est que ce dernier s'adapte en temps réel aux ressources de la machines, et permet d'exploiter au mieu le matériel. Et lors d'une mise à jour importante, apparition d'un nouveau type de matériel nécessitant une nouvelle optimisation, t'as juste à mettre à jour le SDK sans devoir retoucher le programme.
 
Alors pour faire un générateur de clés SSL, le .NET n'est pas forcément ce qu'il y a de mieu (mais le C++ non plus, puisque même le C c'est limite, l'ASM est le seul à permettre suffisament d'optimisations pour faire une bibliothèque performante), le .NET reste très largement supérieur à du compilé pour faire un outils serveur, tel un ERP.
 
Et en chiffre d'affaire, lignes de code et tout ce que tu veux, un ERP est autrement plus important qu'un lecteur de MP3...
 
Encore un truc, SQL Server 2002 est écrit pour la majeure partie en C#. tu trouve qu'il ramme toi ? Moi je trouve pas. C'est quand même un concurrent potentiel à Oracle des plus sérieux.
 
Une partie du noyau de Win2K est d'ailleurs aussi écrit dans un pseudo C# (son ancêtre)
 
En effet, M$ à développé au départ le .NET en interne, pour leur simplifier la vie dans leurs développement. Se retrouvant avec un langage capable d'apporter un réel plus sur le marché, et un SDK digne d'intérêt, ils ont décidé en d'aire un projet à part entière et le commercialiser.
 
Maintenant, compare la rapidité de Win2K et NT4 (qui lui est full C/C++) et tu vas me dire en quoi .NET est plus lent.

zeux
Quand on fait des réallocations, le déplacement en mémoire est probablement incontournabme, et les pointeurs/itérateurs ne suivent pas.
La parade, c'est d'estimer les besoins et de pré-réserver l'espace.
Il est impardonnable que la doc MFC n'en parle pas, comme le fait celle de la STL.
 
Les allocations new/delete à la sauce C++ n'ont pas d'équivalent à realloc.
C'est un choix discutable, d'ailleurs il manque une sémantique de déplacement à C++.

C'est trop gros, même sans avoir vu une ligne de code C# !
 
D'abord, le C++ conserve une compatibilité maximale avec le C.
Le C++ tout entier est conçu autour de concepts fondamentaux à la programmation, et très proche de la machine.
Je suppose que C# a choisi comme Java la voie de la facilité pour le programmeur, au prix de la performance et de la richesse de concepts.
 
Ce que je comprends, c'est que C++ souffre de son héritage ancien, et qu'il pourrait régrésser en tenant vis-a-vis des nouveaux langages le rôle que l'assembleur tient vis-a-vis du C/C++: fondamental, mais ardu.
 
 
A part ça, je suis plutôt d'accord sur tes remarques sur le runtime, le code natif et l'adaptation en temps réel aux ressources.
Mais je pense que rien ne s'oppose à ce que C++ dispose d'un tel 'adaptateur intermédiaire'.

 
Mon cher Harkonnen, ne t'emportes pas comme ça, on a l'impression que tu as absolumment besoin d'être rassuré sur tes capacités de développeurs; je ne les mets pas en doute, simplement l'arrogance de tes précedents messages, m'a obligé a déconner un peu, histoire de te remettre en place;
si tu veux parler de compétances, ça fait 15ans que je développe du soft, je bosse dans un milieu de haute technologie ou je developpe des softs pour Intel, ST Microelectronics, et plus globalement tous les fabriquants de composants electroniques. Pas le droit à la moindre erreur quand on controle la production de ces géants de l'insdustrie; alors la qualité d'un soft, tu penses bien que je sais ce c'est depuis longtemps.
 
Quand à toi, change de métier, le tient semble te frustrer au plus haut point, et quand tu répondras aux topiques à l'avenir, évite de critiquer les personnes du forum, et répond plutôt intelligemment.
 
Sans rancune, à+
 
     

De toute maniére personne n'oblige personne à jeter son VS6/GCC/npqkoidotre pour C#
On echange des opinions entre gens ""civilisés""
 
Bref, sino, par acquis de conscience g kan meme remis le framework NET sur ma becane de boulot.
 
Oui c mieux pour ecrire du code bien propre.
Oui l'IDE c jolie etc ...
 
Mais bon comme vieux briscard du C/C++ ca manque de saveur ..
 
Pour les gens ki gerbe sur le compilo de VS6, +1 ...
y a pas que ca ds la vie, bon evidemment je parle pas pour les
gens qui bossent chez des boites ki ont deja fait un choix ...
 
Et bonne nouvelle g reussi a faire marcher mon prog C# !!
 
tout n'est pas perdu, a l'heure ou blanchi la campagne , fuyons ... (clin d'oeil au lectuer de Amstrad 100%)

 
D'abord, je voudrais bien savoir où j'ai été arrogant dans mes propos !!!
Je n'ai fait que dire que j'arrivais à compiler du .NET sans problème et puis voila... Elle est ou l'arrogance la ???
C'est plutot toi qui a commencé, en me demandant si je n'étais pas prof pour etre aussi con, et en traitant mes programmes de simplistes ! Tu sais, je ne suis qu'un modeste analyste programmeur, je n'ai que 5 ans d'expérience en tout, je suis surement une sous merde à coté de toi... Mais bon, je ne me permets pas d'insulter les autres comme tu l'as fait avec moi !
 
Sans doute que tu penses que le fait de bosser pour des grosses structures aussi pointues te donnes le droit de penser que les programmes des autres sont indignes d'un amstrad CPC, tu penses ce que tu veux après tout...
 
Moi je n'ai fait que répondre à ton topic, sans ajouter de polémique ! Tu souhaitais connaitre un avis sur .NET, je te l'ai donné et basta...
 
Quant au fait que mon boulot soit frustrant, tu n'y est pas du tout ! Au contraire, j'adore mon boulot et il me permet de tenir en ce moment, car je traverse quelques épreuves difficiles...
 
Je n'ai pas envie de polémiquer, je n'ai pas le temps de toute façon. Je te rassure, tu ne m'as pas du tout remis à ma place, tu m'as au contraire confirmé ma 1ere impression : tu es un boolay qui ne se sent plus pisser !
 
 

Juste une derniere chose au sujet de mes réponses intelligentes dans ce forum : fais donc une recherche sur mes posts, et tu constateras de visu mes réponses... Et tu pourras constater que mes réponses valent largement les tiennes... Si toutefois tu en a apporté !

 
je pige pas là... tu peux expliquer ?

antp a écrit a écrit :     je pige pas là... tu peux expliquer ?

Ben pour une majeur partie des traîtements (même en faisant abstraction du matériel, par exemple pour un SGBD, Win2K est plus rapide que NT 4, et pourtant Win2K est en partie en C# (pas exactement, puisque c'est son ancêtre, mais bon)
 
ce que je veux dire par là, c'est que le 100% compilé où je sais exactement ce que ça donne en ASM au final n'est pas forcément plus rapide que du code compilé à la volée par un runtime. Ca dépends de beaucoup de choses, et notamment pour les très gros traîtements (gestion mémoire d'un OS par exemple) avec un programme capable de s'adapter en temps réel aux ressources de la machine peut s'avérer plus efficace qu'un programme optimisé pour une structure précise, car quand cette dernière change ça va plus du tout.

yung3001 & harkonnen > bon, on arrête maintenant
 
C'est du haut de mes 3 ans d'expérience en ASP (:D) que je vous le dit : franchement c'est con de se battre parcequ'on ne se comprends pas mutuellement.

mon petit avis de débutant sur net > VS .net est une bombe, carrement fort comme interface, je connais plusieurs dévellopeur qui sont tombé sur le cul quand a son ergonomie et sa facilité d'utilisation
 
voili voilou

D'accord avec toi casqetta, l'interface est tres reussie, mieux que celle de son prédécesseur ! Et ca c'est un plus indéniable !
 
Hihi, je me doutais bien que ce topic dégenèrerais un peu   . Quoiqu'il en soit, je voyais harkonen comparer c# et c++. Si a première vue on peux se dire que c# est la pour concurancer le java, ben il concurance aussi le C++. Je parle de mon experience, inutile de crier au fou
 
J'ai fait un jeu (pas tout a fait fini), il y a 1 an avec qques copains. On l'avait commencé en java, mais on a vite été limité niveau vitesse d'affichage, on s'est donc tourné vers le c++ et l'openGL.  
 
Récemment, apres avoir testé le c#, je (je suis seul maintenant ) l'ai passé dans ce langage.
Résultat des courses :  
 
Syntaxe : en une semaine, j'avais convertit la plus grosse partie du prog et simplifié a mort la syntaxe (et ca c super important, les (*Maclasse)->methode(truc->id) ca gave a la longue, c pas clair).  
 
Vitesse d'execution : identique, c'est un jeu de type Pong multijoueur en reseau avec affichage en openGL, aucune différence, et pourtant c'est un langage interprété avec un garbage collector !!!!!  
En plus j'utilise à tour de bras l'instruction foreach du c# qui d'apres M$ peut etre plus lente qu'une boucle for dans certains cas !!
 
Le garbage collector, parlons en : c'est génial, c'est vraiment bien de ne pas se soucier de ses objets comme en java, c'est vraiment un plus !
 
Les classes predefinies : comme en java yen a des tas. J'ai trouvé tout ce qu'il me faut. Je me suis meme lancé dans le xml pour parser les niveaux, c super simple.
 
Pour finir, je le rapelle : meme vitesse d'execution C++/c# et pourtant y a des tas de calculs non entiers sur des matrices et tout !
 
Voila.

Dernier truc : a moins d'etre un afficionados des MFC, pour faire un prog windows, il vaut mieux le faire en c#.
 
Enfin, c'est ce que je pense. (en solution microsoft, evidement, inutile de crier : "En delphi, c mieux", je m'en fous !)

ben tu sais franchement parser du xml qui n'est qu'un banal fichier texte structuré c pas sorcier hein ?
 
ensuite avant de faire des comparaison de vitesse entre c# et du c++ il faut se demander si la majeure partie de tes traitement ne sont pas réalisé par les dlls qui sont derrière ton c# ... ça m'étonnerait fortement qu'elles soient elles aussi en p-code    
 
c'est un peu comme avec les scripts qui manipulent le moteur 3d d'un jeu...faut pas croire que le moteur est réalisé en script    
 

Mais je m'en fous que ce soit des dll ! Je dis simplement que c aussi rapide et plus simple a ecrire, plus claire avec un garbage collector, qu'il y a tout un tas de classes prédefinies.
Et que c'est en langage certes interprété mais rapide !
 
 
Quant au xml, ben oui c un fichier txt, mais fait donc un parseur en c, tu va te faire chier. J'y arriverais, j'avais commencé a le faire en c++, mais c chiant et y faut debuguer. Là ce que je voulais dire c'est que c'est deja fait, et bien fait ! C'est ca de moins a se taper. Dans un prog on peut pas tout faire soit meme !  

bien sur que tu peux pas faire tout tout seul mais bon faut pas non mettre c# à toute les sauce et mettre au rencart c++ car bon des classes toutes faites pour parser du c++ (c pas compliqué quand meme) ben tu en as des douzaines et on a pas non plus toujours envie de se trimbaler les tonnes de dlls de .net pour faire un petit prog windows...  
 

bah le peu que g vu de .net me plait bien, mais.....quelqu'un a de la RAM en rab ?

Taureau a écrit a écrit : bien sur que tu peux pas faire tout tout seul mais bon faut pas non mettre c# à toute les sauce et mettre au rencart c++ car bon des classes toutes faites pour parser du c++ (c pas compliqué quand meme) ben tu en as des douzaines et on a pas non plus toujours envie de se trimbaler les tonnes de dlls de .net pour faire un petit prog windows...

Pour les "tonnes" de DLLs du .NET je reprendrai l'argument très pertinent de je ne sais plus qui :
-> En java, tu te tapes une machine virtuelle qui pèse assez lourd aussi.
-> Dès que tu utilises un objet COM dans un prog en C++, si tu veux faire propre, tu ne dois pas l'inclure dans ton code, mais l'ajouter à ton install, donc tu te tapes aussi des DLLs de toute façon.
 
Deplus, le SDK de .NET est inclu d'office dans XP, et le sera sur tout les environnement M$ à venir, donc c'est un faux problème. Si aujourd'hui en effet ça représente une certaine barrière, demain ce n'en sera plus une.
 
 
Sinon, truc qui n'a rien à voir... Ici, y'a des gens qui maîtrisent le C#...
Personne veut me donner un petit exemple de prog multi-threadé ?
 
Avec un main qui lance des treads et les manage... Et une interopérabilité entre deux types de thread : producteur et consommateur...
 
Cf. topic :
http://forum.hardware.fr/forum2.ph [...] h=&subcat=

MagicBuzz a écrit a écrit :   Personne veut me donner un petit exemple de prog multi-threadé ?   Avec un main qui lance des treads et les manage... Et une interopérabilité entre deux types de thread : producteur et consommateur...

 
M'interresse aussi, mon prog est multithread, mais sans semaphores (les classes mutex & co sont assez obscures, et l'aide de .NET est vraiment pas un modèle du genre), ce qui fait qu'il est potentiellement explosif.

 
faut pas pousser quand meme un objet COM ne t'imposera jamais le surcout de .NET c aussi ridicule que de dire qu'un p-code est aussi rapide que du natif, on a déjà lu ça avec vb puis java puis avec les JIT bref bien sur qu'un jour ...
 
mais .net dispose de la meme tare que java c'est un gros consommateur de mémoire alors là encore tu vas me dire que tout le monde dispose de 512Meg ok ok mais franchement je trouve que pour faire un PONG c'est un peu disproportionné d'utiliser .net