Pour démontrer que le compilateur est mauvais, je te demande juste de montre ce qui ne va pas dans le compilateur ou à défaut de me présenter un compilateur alternatif.
Toi tu me proposes un compilateur qui fait autre chose (qui traduit un autre langage), c'est vrai que pour comparer c'est pratique.
Ce qui tourne sous .NET à peu de chance de tourner correctement sous Mono
Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?
En plus, l'ABI C++ de gcc 3.* changeait beaucoup.
Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.
Ca reste à démontrer: montre moi un compilateur plus rapide pour le même langage (sans toucher à la sémantique du langage, cad en offrant exactement les mêmes services).
Ok donc sachant qu'il n'y a pas de grosses différences à l'exécution entre une pré-compilation en code natif et la technique JIT en ce qui concerne le C#, on en déduit très logiquement que la VM n'a quasiment aucun impact.
Et comment tu fais les allocations dans la pile pour les objets automatique ?
Effectivement.
Dans ce cas tu te prives de beaucoup de possibilités d'optimisation,
Des fois je préfères moins d'optimisation :)
Il doivent être compiler, donc cela parait difficile.
Pré-compilé.
Mais bon c'est tout le concept des templates que je trouve foireux.
Chaque élément de compile doit avoir toutes les infos.
Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.
Tu sais très bien qu'on a pas la même définition, pour toi VM = interpréteur ou JIT.
Cette définition n'a aucun intérêt dans le cas de C# où l'on peut se passer de ces 2 modes d'exécution et produire un binaire natif.
Moi j'appelle un interpréteur un interpréteur, et un JIT un JIT.
Je propose des pistes, effectivement y'a le problème de la taille de l'objet, ce qui peut difficilement être réglé sans changer la sémantique du new (on pourrait imaginer que c'est la classe qui fait concrêtement la réservation mémoire).
Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.
Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).
Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.
Les structures/classes sont des abstractions de la mémoire de l'ordinateur,
Enfin en C ce n'est pas vraiment une abstraction, plutôt une organisation.
Mais oui, la limite est flou. Comme je le dis plus haut, en étant relativement portable (et donc relativement indépendant du jeu d'instruction machine), on peut définir une VM (un jeu d'instruction) qui serait l'ensemble nécessaire pour le langage C.
Et il le jette à la poubelle une fois le code machine généré,et c'est exactement ça la différence, à mon sens, entre une VM et un code natif.
Bah tu peux compiler du C# en code natif et ne garder que les métadonnées nécessaires à l'introspection (ce que propose mono). Exactement comme le fait C++ pour rendre son service d'introspection.
La limite est vraiment flou, et tout est une question de niveau d'abstraction.
Désolé, mais pour moi la limite est vraiment trop flou pour pouvoir dire "tel langage utilise une VM", "tel autre non".
Tu peux compiler du C# en natif (c'est prévu dès le départ)
Tu peux compiler du C++ en natif
Tu peux compiler du C# en bytecode .NET
Tu peux utiliser un backend .NET pour GCC
Un compilateur comme GCC utilise une représentation intermédiaire avant de transformer en code natif
Un compilateur comme mcs utilise une représentation intermédiaire avant que mono transforme en code natif.
Je préfères ma définition : une machine virtuelle est définie par un ensemble de jeu d'instruction différent du jeu d'instruction réel sur lequel s'exécute le programme.
En étant relativement portable, un langage comme C s'appui implicitement sur une certaine abstraction du code machine.
Dans tous les cas les processus d'exécution sont au final très proche, et ce qui change, c'est essentiellement la sémantique du langage (et donc l'ens
emble des optimisations que peut réaliser le compilateur) et l'ensemble des services sur lesquels se base le langage (et des langages comme C++ montre que même à "bas-niveau" il y en a).
Ta définition de VM (code intermédiaire nécessaire) me paraît trop réducteur. Je suis convaincu que l'on peut faire un compilateur C# qui génère directement du code machine.
Si le bytecode est une réalité et que le compilateur C# cible un bytecode, c'est d'abord une question de déploiement : il est plus simple de déployer du bytecode que 15 versions de ton exécutable pour les 15 plateformes que tu veux supporter.
Tu tournes autour du pot, ta critique est qu'il te faut avant tout une application qui tourne bien sous Windows et qui tourne accessoirement sur d'autres OS.
Moi je te parle de technos libres : GTK, Qt, toi tu me réponds WinForms.
Désolé, on est sur LinuxFR, on a pas les mêmes priorités.
Comme actuellement : les gens n'auront pas accès à leur compte gmail, à leur youtube, leur twitter et autres conneries 2.0 :)
Faut bien voir qu'à mon avis le public visé est le plus déjà conquis.
Ce qui me fait hurler, c'est les .h, et uniquement les .h.
Cette possibilité qu'il y a à mettre du code dans un .h avec toutes les merdes que cela entraîne.
Qui ne sait jamais fais avoir parcqu'il a ajouté un champs private dans sa classe (dans le .h forcement) et qui se retrouve avec une application compilé avant qui saute parcqu'elle fait une allocation de ton objet mais qui a changé de taille dans ton implémentation ?
Qui ne s'est jamais résolu à cantonner la section private à un pointeur vers une structure pour éviter ce problème (la taille de la classe ne bougeant alors plus, seule la structure évolue) ?
Qui ne s'est jamais pris la tête avec un #pragma ou autre connerie pas fermée dans un .h et qui te fou la grouille pas possible dans ton programme parcque t'as inversé 2 #includes ?
Qui ne sait jamais dis : mais pourquoi les templates sont déclarés dans les .h ??
C'est pas uniquement parcque l'introspection n'est pas présente en C++, c'est surtout parcque on peut tout et n'importe quoi dans un .h. Il aurait fallu définir clairement son contenu et le cantonner à du déclaratif uniquement, surtout pas de code ou d'exposition de données privées (champs private).
Sous Linux tu vas utiliser C# + GTK# + ...
Bah sous Windows ca marche très bien GTK#, c'est quoi le problème ?
Et tout ce qu'avait apporté Java dans le domaine du multiplateforme (meme si ce n'etait pas parfait), .NET fait un trait dessus. Un grand retour en arriere, c'était quand meme l'innovation la plus flagrante de Java. Es un hasard ?
non c'est pas un hasard. MS avaient d'autres objectifs que ceux de Sun et a donc pondu une plateforme différente.
Tout ce qui est multiplateforme est une atteinte au monopole de Windows.
Microsoft distribue Silverlight sous Mac.
C# et CLI sont standardisés + sous Community Promise mais surtout pas les librairies autour.
Une partie des libs de base si quand même.
Le jour où WinForms/WPF, je ferais du .NET les yeux fermés.
Je comprends pas, tu attends la libération des API proprio intégrées à Windows pour utiliser .NET plutôt que d'utiliser les toolkits existants que sont GTK ou Qt ?
Ca me dépasse.
donc, si l’un des objets membres présente l’interface IDisposable, il faut faire de même.
Je suis d'accord.
Mais désolé on code pas le même type d'appli, mes objets métiers sont pour la plupart indépendant de quelconques objets exposant IDisposable :)
En Java, le garbage collector est beaucoup plus prompt à se déclencher,
C'est très subjectif ce que tu dis. Dans tous les cas me dis pas que c'est techniquement plus facile de coder en Java parcque le garbage collector passe un peu plus souvent, c'est un peu abhérent.
; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
Bah alors conclu pas que c'est plus facile en Python pour ce problème spécifique.
en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance.
Ca c'est dangereux, tu peux te retrouver avec des problèmes de perf liée marshaling, mais là on déborde du problème de la VM pure, c'est pas forcement plus évident de travailler avec JNI en Java et t'as d'autres types de problèmes bien plus enmerdant que le C++ mixé.
Je ne comprend pas comment une fonctionnalité se transforme en défaut pour toi.
C'est pas une fonctionnalité qui se transforme en défaut. C'est comme toute fonctionnalité : ca a des avantages et des inconvénients. L'avantage est d'avoir un type de donnée proche de la machine pour avoir de meilleur performance, l'inconvénient c'est la portabilité.
Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
Juste que j'ai pas choisi la bonne option du bon compilateur.
Les int tenaient sur 16 bits à une époque. Un programme conçu à cette époque et recompilé sur un 32 bits peut donc avoir des souçis si le programmeur n'as pas pensé à l'avenir.
Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme,
Il n'en ai pas forcement conscient. Moi le premier je me suis fait avoir.
C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
On doit traduire un algo que l'on a dans la tête dans le langage de la machine (en tout cas un langage qui sera traduit pour la machine). Il y a forcement des erreurs de traductions dans l'interface chaise/clavier que veux-tu.
L'avantage avec C# est évident : tu ne peux pas.
C# a maintenant 8 ans :)
Désolé, mais non : tu donnes des exemples qui ont pour résultat :
- C : on a des problème car ça a mal été codé.
- C# : on doit tout recoder.
???
Si mon programme C# a 8 ans, je fais quoi en C ? je recode tout. Je comprends rien à ton argument foireux.
Technique non standardisée dont chaque compilateur a sa version. Mais certes c'est un niveau d'information supplémentaire. Bien loin de ce que propose la décompilation d'un bytecode C# ou Java.
Ok, donc toi ta définition de VM, c'est VM = JIT.
Admettons. Donc le monde est parfait, y'a pas de soucis, C# n'utilise pas de VM du moment que t'utilises la bonne option sur ta machine de dev.
Bizzare, ca change quasiment rien à l'exécution mais ca vaut un débat de 500 commentaires.
Un int (le plus utilisé) reste sur 32 bits.
Ok autant pour moi. M'enfin le problème est bien réel pour le long.
Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait
Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel. Par contre je ne pensais pas que mon programme aurait un comportement différent parcque je change d'OS. Désolé de ne pas lire les petites lignes et de faire cette grossière erreur de débutant.
Si tu apprends, tu apprends int64_t
mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans, personne qui ne connaissais même pas d'architecture 64 bits, et tu te retrouves à dépatouiller un bug de merde qui est passé à travers les mailles du débuggueur.
Et encore, c'est vraiment la merde parcque ton client t'as remonté le soucis, mais tu le reproduits pas sur ta machine (t'as une machine 32 bits et tu soupçonnes pas un instant que ton client utilise autre chose).
Tu perds du temps, quand tu commences à comprendre tu es obligé de te taper une analyse fine du code, tu commences à demander au client que compilo il utilise, sur quel OS, tu tentes de reproduire, et tu te dis que le monde est vraiment pourri de perdre du temps sur ce genre de connerie.
'interface IDisposable est utilisée par de très (trop) nombreuses classes
Mais t'as généralement pas besoin de les appeler.
A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ?
Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).
Je connais personne qui ai eu besoin de faire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
Ah, AppDomain::Unload :
On est d'accord, dans .NET 2.0, le système t'offre aucune garantie. Donc en gros tu n'utilises jamais.
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité.
On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
C'est ta "vision" qui est fausse
C'est marrant ces gens qui voudraient imposer leur vision. C'est une question de point de vue, je suis le premier à le reconnaître.
Une machine virtuelle est juste la simulation d'une machine.
une machine virtuelle c'est juste une machine qui n'existe pas.
que ce soit un sous-ensemble d'un jeu d'instruction d'une machine réelle, un sur-ensemble, une abstraction partielle ou complète, dans tous les cas c'est une nouvelle machine qui est virtuelle.
L'introspection c'est la capacité d'un programme à consulter son propre état.
Pas son état mais sa représentation. Si je veux connaître le type d'un objet à l'exécution, il faut que cette information soit disponible à l'exécution. En C# ou en C++ c'est exactement fait de la même façon : une donnée (qui n'est pas l'instruction machine) représentant le type (on l'appel métadonnée) et un morceau de code (runtime) se charge de simuler ce que la machine n'offre pas (l'accès à cette information).
Le langage m'expose une instruction virtuelle qui n'est pas directement mappée sur une instruction machine.
une VM comme Java ou .NET impose une sémantique dans le bytecode qui limite les optimisations et facilite la décompilation. C'est un fait.
Un programme C++ compilé directement en code machine ne pourra être relu qu'en assembleur. Ton compilateur java aura beaucoup faire toute la tambouille que tu veux avec ton code, tu verras toujours tes classes, tes méthodes, tes interfaces, tes appels de méthodes, etc.
Ca sera toujours plus lisible.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Toi tu me proposes un compilateur qui fait autre chose (qui traduit un autre langage), c'est vrai que pour comparer c'est pratique.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?
En plus, l'ABI C++ de gcc 3.* changeait beaucoup.
Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Effectivement.
Dans ce cas tu te prives de beaucoup de possibilités d'optimisation,
Des fois je préfères moins d'optimisation :)
Il doivent être compiler, donc cela parait difficile.
Pré-compilé.
Mais bon c'est tout le concept des templates que je trouve foireux.
Chaque élément de compile doit avoir toutes les infos.
Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Cette définition n'a aucun intérêt dans le cas de C# où l'on peut se passer de ces 2 modes d'exécution et produire un binaire natif.
Moi j'appelle un interpréteur un interpréteur, et un JIT un JIT.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.
Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).
Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Enfin en C ce n'est pas vraiment une abstraction, plutôt une organisation.
Mais oui, la limite est flou. Comme je le dis plus haut, en étant relativement portable (et donc relativement indépendant du jeu d'instruction machine), on peut définir une VM (un jeu d'instruction) qui serait l'ensemble nécessaire pour le langage C.
Et il le jette à la poubelle une fois le code machine généré,et c'est exactement ça la différence, à mon sens, entre une VM et un code natif.
Bah tu peux compiler du C# en code natif et ne garder que les métadonnées nécessaires à l'introspection (ce que propose mono). Exactement comme le fait C++ pour rendre son service d'introspection.
La limite est vraiment flou, et tout est une question de niveau d'abstraction.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tu peux compiler du C# en natif (c'est prévu dès le départ)
Tu peux compiler du C++ en natif
Tu peux compiler du C# en bytecode .NET
Tu peux utiliser un backend .NET pour GCC
Un compilateur comme GCC utilise une représentation intermédiaire avant de transformer en code natif
Un compilateur comme mcs utilise une représentation intermédiaire avant que mono transforme en code natif.
Je préfères ma définition : une machine virtuelle est définie par un ensemble de jeu d'instruction différent du jeu d'instruction réel sur lequel s'exécute le programme.
En étant relativement portable, un langage comme C s'appui implicitement sur une certaine abstraction du code machine.
Dans tous les cas les processus d'exécution sont au final très proche, et ce qui change, c'est essentiellement la sémantique du langage (et donc l'ens
emble des optimisations que peut réaliser le compilateur) et l'ensemble des services sur lesquels se base le langage (et des langages comme C++ montre que même à "bas-niveau" il y en a).
Ta définition de VM (code intermédiaire nécessaire) me paraît trop réducteur. Je suis convaincu que l'on peut faire un compilateur C# qui génère directement du code machine.
Si le bytecode est une réalité et que le compilateur C# cible un bytecode, c'est d'abord une question de déploiement : il est plus simple de déployer du bytecode que 15 versions de ton exécutable pour les 15 plateformes que tu veux supporter.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Moi je te parle de technos libres : GTK, Qt, toi tu me réponds WinForms.
Désolé, on est sur LinuxFR, on a pas les mêmes priorités.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: C'est normal...
Posté par TImaniac (site web personnel) . En réponse au journal Google OS. Évalué à 5.
Faut bien voir qu'à mon avis le public visé est le plus déjà conquis.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Cette possibilité qu'il y a à mettre du code dans un .h avec toutes les merdes que cela entraîne.
Qui ne sait jamais fais avoir parcqu'il a ajouté un champs private dans sa classe (dans le .h forcement) et qui se retrouve avec une application compilé avant qui saute parcqu'elle fait une allocation de ton objet mais qui a changé de taille dans ton implémentation ?
Qui ne s'est jamais résolu à cantonner la section private à un pointeur vers une structure pour éviter ce problème (la taille de la classe ne bougeant alors plus, seule la structure évolue) ?
Qui ne s'est jamais pris la tête avec un #pragma ou autre connerie pas fermée dans un .h et qui te fou la grouille pas possible dans ton programme parcque t'as inversé 2 #includes ?
Qui ne sait jamais dis : mais pourquoi les templates sont déclarés dans les .h ??
C'est pas uniquement parcque l'introspection n'est pas présente en C++, c'est surtout parcque on peut tout et n'importe quoi dans un .h. Il aurait fallu définir clairement son contenu et le cantonner à du déclaratif uniquement, surtout pas de code ou d'exposition de données privées (champs private).
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bah sous Windows ca marche très bien GTK#, c'est quoi le problème ?
Et tout ce qu'avait apporté Java dans le domaine du multiplateforme (meme si ce n'etait pas parfait), .NET fait un trait dessus. Un grand retour en arriere, c'était quand meme l'innovation la plus flagrante de Java. Es un hasard ?
non c'est pas un hasard. MS avaient d'autres objectifs que ceux de Sun et a donc pondu une plateforme différente.
Tout ce qui est multiplateforme est une atteinte au monopole de Windows.
Microsoft distribue Silverlight sous Mac.
C# et CLI sont standardisés + sous Community Promise mais surtout pas les librairies autour.
Une partie des libs de base si quand même.
Le jour où WinForms/WPF, je ferais du .NET les yeux fermés.
Je comprends pas, tu attends la libération des API proprio intégrées à Windows pour utiliser .NET plutôt que d'utiliser les toolkits existants que sont GTK ou Qt ?
Ca me dépasse.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
L'âge n'y es pour rien.
Tu inventes des problèmes qui n'existent pas et apporte des solutions impossibles
Vrai problème rencontré dans la vraie vie.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Je suis d'accord.
Mais désolé on code pas le même type d'appli, mes objets métiers sont pour la plupart indépendant de quelconques objets exposant IDisposable :)
En Java, le garbage collector est beaucoup plus prompt à se déclencher,
C'est très subjectif ce que tu dis. Dans tous les cas me dis pas que c'est techniquement plus facile de coder en Java parcque le garbage collector passe un peu plus souvent, c'est un peu abhérent.
; en python, je ne sais pas, car je n’ai jamais construit de très grosse application en Python.
Bah alors conclu pas que c'est plus facile en Python pour ce problème spécifique.
en créant un objet mixte (C++ managé et C++ non-managé), si l’on veut avoir de très bonne performance.
Ca c'est dangereux, tu peux te retrouver avec des problèmes de perf liée marshaling, mais là on déborde du problème de la VM pure, c'est pas forcement plus évident de travailler avec JNI en Java et t'as d'autres types de problèmes bien plus enmerdant que le C++ mixé.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est pas une fonctionnalité qui se transforme en défaut. C'est comme toute fonctionnalité : ca a des avantages et des inconvénients. L'avantage est d'avoir un type de donnée proche de la machine pour avoir de meilleur performance, l'inconvénient c'est la portabilité.
Tu te raccroches aux branches car tu vois que ton int argumenté ne tient pas la route, et va sur long dont l'offre est faite pour ce qu'il fait (dépendant de la plate-forme), hum...
Juste que j'ai pas choisi la bonne option du bon compilateur.
Les int tenaient sur 16 bits à une époque. Un programme conçu à cette époque et recompilé sur un 32 bits peut donc avoir des souçis si le programmeur n'as pas pensé à l'avenir.
Quand une personne demande expressément que son entier soit de taille différente suivant la plate-forme,
Il n'en ai pas forcement conscient. Moi le premier je me suis fait avoir.
C'est la personne qui ne sait pas communiquer, si je dis A quand je pense B, personne ne peut savoir que je pense B.
On doit traduire un algo que l'on a dans la tête dans le langage de la machine (en tout cas un langage qui sera traduit pour la machine). Il y a forcement des erreurs de traductions dans l'interface chaise/clavier que veux-tu.
L'avantage avec C# est évident : tu ne peux pas.
C# a maintenant 8 ans :)
Désolé, mais non : tu donnes des exemples qui ont pour résultat :
- C : on a des problème car ça a mal été codé.
- C# : on doit tout recoder.
???
Si mon programme C# a 8 ans, je fais quoi en C ? je recode tout. Je comprends rien à ton argument foireux.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
donc C# n'a toujours pas de VM quand il est utilisé avec la bonne option.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Admettons. Donc le monde est parfait, y'a pas de soucis, C# n'utilise pas de VM du moment que t'utilises la bonne option sur ta machine de dev.
Bizzare, ca change quasiment rien à l'exécution mais ca vaut un débat de 500 commentaires.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ok autant pour moi. M'enfin le problème est bien réel pour le long.
Quelqu'un qui a mis "long" doit le faire en sachant ce qu'il fait
Oué je développe sous un OS 64 bits et je constate qu'un long me permet d'avoir un algo fonctionnel. Par contre je ne pensais pas que mon programme aurait un comportement différent parcque je change d'OS. Désolé de ne pas lire les petites lignes et de faire cette grossière erreur de débutant.
Si tu apprends, tu apprends int64_t
mais tu peux aussi te retrouver à compiler un code écrit par une tierce personne, y'a 5 ou 10 ans, personne qui ne connaissais même pas d'architecture 64 bits, et tu te retrouves à dépatouiller un bug de merde qui est passé à travers les mailles du débuggueur.
Et encore, c'est vraiment la merde parcque ton client t'as remonté le soucis, mais tu le reproduits pas sur ta machine (t'as une machine 32 bits et tu soupçonnes pas un instant que ton client utilise autre chose).
Tu perds du temps, quand tu commences à comprendre tu es obligé de te taper une analyse fine du code, tu commences à demander au client que compilo il utilise, sur quel OS, tu tentes de reproduire, et tu te dis que le monde est vraiment pourri de perdre du temps sur ce genre de connerie.
[^] # Re: Un autre bonne raison de ne pas utiliser Mono
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Mais t'as généralement pas besoin de les appeler.
A part dans des situations où tu fais de très nombreuses allocation d'objet auquel cas tu veux rendre très rapidement la mémoire, je vois pas l'intérêt. Tu fais pas de foreach(var i = 0;i++;i<1000000) new Form() si ?
Sur 50 classes que je développe, je dois implémenter IDisposable 1 fois.
Sur un exemple simple non, mais lorsque tu as de multiples références sur ta classe, tu fini par ajouter des AddRef et des Release sur tes classes pour gérer ton propre compteur de référence, sa tombé à 0 appelant la méthode Dispose (pour éviter un pénurie de ressource non-managées).
Je connais personne qui ai eu besoin de faire ça, mais admettons que tu es ce besoin. Expliques moi en quoi c'est différent en Java ou en Python, en quoi c'est moins technique vis-à-vis de ce problème.
Ah, AppDomain::Unload :
On est d'accord, dans .NET 2.0, le système t'offre aucune garantie. Donc en gros tu n'utilises jamais.
Tu as lu la page, c'est complètement ubuesque, on rajoute une couche de complexité.
On s'en fou c'est caché. Pour le développeur c'est toujours moins complexe que de gérer la mémoire à la main.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
C'est marrant ces gens qui voudraient imposer leur vision. C'est une question de point de vue, je suis le premier à le reconnaître.
Une machine virtuelle est juste la simulation d'une machine.
une machine virtuelle c'est juste une machine qui n'existe pas.
que ce soit un sous-ensemble d'un jeu d'instruction d'une machine réelle, un sur-ensemble, une abstraction partielle ou complète, dans tous les cas c'est une nouvelle machine qui est virtuelle.
L'introspection c'est la capacité d'un programme à consulter son propre état.
Pas son état mais sa représentation. Si je veux connaître le type d'un objet à l'exécution, il faut que cette information soit disponible à l'exécution. En C# ou en C++ c'est exactement fait de la même façon : une donnée (qui n'est pas l'instruction machine) représentant le type (on l'appel métadonnée) et un morceau de code (runtime) se charge de simuler ce que la machine n'offre pas (l'accès à cette information).
Le langage m'expose une instruction virtuelle qui n'est pas directement mappée sur une instruction machine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Un programme C++ compilé directement en code machine ne pourra être relu qu'en assembleur. Ton compilateur java aura beaucoup faire toute la tambouille que tu veux avec ton code, tu verras toujours tes classes, tes méthodes, tes interfaces, tes appels de méthodes, etc.
Ca sera toujours plus lisible.