TImaniac a écrit 6423 commentaires

Et cela se passe comme une fleur avec la partie commune ?
Ben c'est comme tout, ca dépend des parties dont tu parles évidemment.
Pour ce qui concerne les libs standards, je n'ai jamais eu de problème de compatibilité.

Tu me dira mono doit faire des testes de conformité avec l'implémentation de MS.
Y'a une batterie impressionnante de tests unitaires pour valider la conformité avec les libs MS.

D'ailleurs, une question à part: est-ce que mono tourne sous d'autre cible que le x86 ?
Ben : http://www.mono-project.com/Supported_Platforms

C'est une blague ?
Ben je connais au moins 3 implémentations différentes, mais bon forcement aucune ne démontre ce que tu avances.

Je t'ai trouvé des exemples de langages ayant les 2 technologies.
Super, mais tu changes plusieurs paramètres, donc tu démontres rien du tout. Peut être que c'est le traducteur JIT de OCaml qui est mauvais, va savoir.
Ou peut être que le principal facteur c'est pas les outils mais la sémantique et les services qu'il y a derrière le langage... Le truc que j'appelle VM.

Je parle des framework MS et ceux de Novell.
Oué oué oué, en gros tu veux parler des libs, c'est là qu'il y a des incompatibilité.
Rien d'anormal, ce sont 2 frameworks différents, avec une partie en commun et chacun des spécificités. Où veux-tu en venir ?

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.

J'ai proposé à la fin des améliorations possible en gardant le principe.

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.

Le problème que t'as aujourd'hui avec les long tu l'avais hier avec les int, c'est tout.
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.

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.

Donc pour toi VM = JIT ou interpréteur.
donc C# n'a toujours pas de VM quand il est utilisé avec la bonne option.

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.

quel est le rapport ?

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.