'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.
Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...
Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
Certes, int n'est pas garanti à 32 bits, il peut faire 64 bits sur une machine 64 bits et 32 sur une machine 32 bits (en pratique : jamais vu).
Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
ou plus standard int64_t, qui date de 1999!
Le programmeur n'est pas parfait et ne connais pas tout.
et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement
Je suis un programmeur débutant, tu comprends j'ai écrits int dans mon programme et ca marchait très bien jusqu'à ce que je change de machine et que ca déborde.
Si : il utilise les types qui correspondent à son besoin
Personne n'est parfait et sait choisir pertinemment le type dont il a besoin. Si les programmeurs étaient parfaits et prenaient toujours les bonnes décisions, on se poserait pas toutes ces questions.
Tu crois que les développeurs Java ou .NET n'ont pas les moyens de fournir d'information aux développeurs et aux compilateurs ?
Si, et pourtant ils n'utilisent pas ces foutus .h qui sont à baffer.
non, typeid suppose la présence d'information et de code complémentaire à l'exécution.
Ce n'est pas directement mappable sur un sous-ensemble d'instruction machine.
A mon bon monsieur, pourquoi interdire le port d'arme à feu ? C'est vrai, malgré cette loi t'auras toujours un con pour se tuer avec un sac en plastique.
C'est pas parcqu'il est impossible d'atteindre le risque 0 qu'il ne faut pas chercher à réduire les risques d'erreur.
C'est aussi un jeu d'instruction particuliers.
Tout à fait.
throw et typeid sont des instructions C++ qui sont tout ce qu'il y a de plus virtuelles (pas directement mappé sur des instructions machines) et participent ainsi à la définition d'une VM.
Personne n'est un dieu comme toi et ne code sans erreur (d'ailleur tu dois coder en assembleur suis-je bête, tu te fais pas chier avec les services offerts par la syntaxe C qui t'offre des garanties à la compilation).
Les pauvres gens comme moi sommes imparfait tu comprends, on a le droit de travailler quand même où on doit changer de métier parcqu'il y a heuresement beaucoup de dieu comme toi ?
Qu'ils soient différents ou pareil ne devrait rien changer au programme.
T'as pensé au débordement ? Style je code sur une machine 64bits, je déploie sur 32bits après avoir fait bien gaffe à ne pas mélanger pointeur et valeur entière... et là paf erreur de calcul ! pourquoi ? Parcqu'à l'exécution mon algo a vite débordé les 32 bits, limitation que je ne voyais pas sur ma machine 64 bits.
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
Je ne vois pas pourquoi le fait de rajouter des métadonnées fait d'un code compilé une VM.
Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution.
Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
Ce que fait un compilateur C : compilation => représentation intermédiaire => code machine exécutable.
Ce que fait un compilateur C# compilation => représentation intermédiaire. Et le runtime : représentation intermédiaire => code machine exécutable.
Sachant qu'il est également possible de faire exactement comme en C, à savoir tout avant l'exécution, il ne faut pas voir dans la compilation la définition de VM.
Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
Très certainement.
C'est faux et archi faux. Tu as tous les LISP, tous les *ML, Scade sont compilé et n'ont pas de VM
On a pas la même définition d'une VM c'est tout.
C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
est une pure expérience du C.
Une pure expérience du code machine, dont les instructions manipulent des tailles de données différentes sur x86 et sur x64, ce qui conduit un langage qui définit une très faible abstraction comme le C a exposé ces différences dans les types primitifs.
Pour mettre sizeof() et non 4, dans ton code.
Sauf que tu peux mettre 4. Le langage n'offre aucune garantie et le programmeur peut se louper. L'erreur est humaine.
Mais il faut être gonfler pour mettre ce risque sur le même plan que le risque juridique anti-FLOSS venant de MS.
C'est exactement le même type de risque, le même type de protection.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Depuis le départ, .NET propose plusieurs langages ce qui en fait une plateforme différente dans l'esprit.
ben non, c'est standardisé aujourd'hui.
Comme C# ca tombe bien.
Cela n'a rien à voir avec une VM qui traduit du bytes code !
Ca c'est ta définition réductrice de VM. Pour moi une VM est tout ce qui constitue une abstraction de la machine. Quand tu proposes un peu d'introspection comme le fait C++, c'est quelque part une VM. Beaucoup plus light qu'une VM de type .NET ou Java parcqu'offrant beaucoup moins de services, on est d'accord.
En plus aujourd'hui, il y a mini 2 coeurs à disposition.
Les perfs sont bien meilleurs avec 2 threads qu'avec 2 processus, à plus forte raison avec 2 vrais coeurs.
M ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
Tu vois moi aussi je peux le dire : n'importe quoi.
mono me permet de compiler directement en code natif mon code C# comme le fait ton compilateur ADA.
Un compilateur comme OCaml permet de faire également les 2.
compilé et VM sont 2 notions différentes.
C'est évident et Ada pond du code machine ! (essaye gnat)
mono et .NET aussi dit donc.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
Il optimise au sein d'une méthode mais il va sûrement pas casser la sémantique des classes/méthodes/héritage, ce qui rendrait toute interopérabilité et l'introspection impossible.
du coup il faut rendre son navigateur autiste et désactiver tout ces plug-ins...
On est d'accord, mais le problème vient plus de la multiplicité de code exposé. Y'a beaucoup trop de code "non fiable" qui se retrouve à tourner dans nos navigateurs.
de la poudre verte.
C'est mon quotidien cette poudre.
les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
Gni ? Rapport ?
Il utilise une protection hardware parfaitement et totalement étanche
Et surtout totalement propriétaire pour une architecture matérielle donnée. L'OS tout seul ne peut rien faire.
C'est une protection hardware, pas software, l'OS ne fait qu'exposer cette protection.
Une VM peut faire cette protection de manière software indépendamment de l'hardware parcqu'elle propose justement une autre vu que le code machine.
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
En pratique, les 2 sont complémentaires, et la gestion hardware est beaucoup trop rigide et pas assez précise (granularité : processus).
Et puis quand tu veux faire du portable (style applet), ben t'as pas le choix d'utiliser une abstraction.
Ce que tu décris, cela s'appelle de la gestion de processus
Non, ca s'appel la gestion de processus au niveau OS parcque c'est le seul cloisonnement que l'OS sait offrir.
Ca s'appel pas comme ca au niveau VM parcque ca se gère pas au niveau processus mais au niveau instruction (chaque instruction est contrôlable et contrôlée).
Là est toute la différence.
GTK en fournis il me semble ?
A condition que tu respectes strictement les conventions de codage imposée par glib. A défaut d'avoir un langage qui offre la fonctionnalité, ils fournissent une lib en partant du principe que le programmeur va respecter les conventions que le compilateur est incapable de vérifier car ce n'est pas dans sa sémantique.
Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
Ben si, en définissant les exception et typeid, C++ défini une VM. De base le code machine ne te propose pas ce genre de mécanisme, le compilateur est obligé d'ajouter du code et le langage de fournir une abstraction pour gérer celà, bref une VM.
tout les langages formels.
qui définissent tous une VM.
comme le javascript ?
javascript fourni au développeur un environnement virtuel d'exécution qui n'a rien à voir avec du code machine, bref une VM.
Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber.
Ca existe toujours.
Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
Et encore, c'est qu'une convention qu'heureusement la plupart respecte... Mais tu retrouves d'autre problème comme le format des bibliothèques qui diffèrent d'un OS à l'autre par exemple.
Non mais en pratique, c'est le cas.
Jor. A quoi sert le sizeof ?
A quoi servent les options -m32 and -m64 de GCC ? Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
Exacte mais est-ce tellement génant ?
Oui, celà demande beaucoup de ressources supplémentaires :
- des développeurs qui s'assurent que le code est "plateforme agnostic" et "compilateur agnostic"
- des packageurs qui doivent prévoir autant de packages
- de l'espace disque pour stocker toutes ces variantes (regarde Debian)
- des ressources machines pour compiler tout ça.
Sans parler du fait que certains ne 's'enmerde' pas à faire tout ce boulot (pas de temps ou soft pas assez populaire pour qu'un mec le fasse à ta place) et tu te retrouves à devoir faire le travail toi même, parfois t'es un simple utilisateur et t'as autre chose à foutre.
Oui c'est génant je crois.
et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Effectivement, ca ne protège pas non plus ta grand mère au carrefour quand elle traverse. Mais ce que tu dis n'est pas faux.
Enfin, tout les langage formels quoi :)
Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.
[^] # 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.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.
dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Drôle
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.
Suffit d'utiliser les options -m32 et -m64 de GCC pour s'en persuader.
ou plus standard int64_t, qui date de 1999!
Le programmeur n'est pas parfait et ne connais pas tout.
et donc mettre int64_t quand tu joue avec des chiffres qui peuvent faire un débordement
Je suis un programmeur débutant, tu comprends j'ai écrits int dans mon programme et ca marchait très bien jusqu'à ce que je change de machine et que ca déborde.
Si : il utilise les types qui correspondent à son besoin
Personne n'est parfait et sait choisir pertinemment le type dont il a besoin. Si les programmeurs étaient parfaits et prenaient toujours les bonnes décisions, on se poserait pas toutes ces questions.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Si, et pourtant ils n'utilisent pas ces foutus .h qui sont à baffer.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ce n'est pas directement mappable sur un sous-ensemble d'instruction machine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
C'est pas parcqu'il est impossible d'atteindre le risque 0 qu'il ne faut pas chercher à réduire les risques d'erreur.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tout à fait.
throw et typeid sont des instructions C++ qui sont tout ce qu'il y a de plus virtuelles (pas directement mappé sur des instructions machines) et participent ainsi à la définition d'une VM.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Les pauvres gens comme moi sommes imparfait tu comprends, on a le droit de travailler quand même où on doit changer de métier parcqu'il y a heuresement beaucoup de dieu comme toi ?
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
T'as pensé au débordement ? Style je code sur une machine 64bits, je déploie sur 32bits après avoir fait bien gaffe à ne pas mélanger pointeur et valeur entière... et là paf erreur de calcul ! pourquoi ? Parcqu'à l'exécution mon algo a vite débordé les 32 bits, limitation que je ne voyais pas sur ma machine 64 bits.
Aucun ingénieur n'est à l'abri d'une erreur comme celle là.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Donc c'est pas ton problème.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Ben le langage expose une sémantique qui n'existe par réellement : il propose une vue virtuelle au programmeur pour lui offrir un service.
La conséquence peut être l'ajout d'information supplémentaire (le code compilé n'étant pas suffisant) pour rendre ce service à l'exécution.
Il n'y a aucun intermédiaire entre le code et la machine, contrairement à une VM.
GCC passe par une représentation intermédiaire, un truc de même niveau que le bytecode.
Ce que fait un compilateur C : compilation => représentation intermédiaire => code machine exécutable.
Ce que fait un compilateur C# compilation => représentation intermédiaire. Et le runtime : représentation intermédiaire => code machine exécutable.
Sachant qu'il est également possible de faire exactement comme en C, à savoir tout avant l'exécution, il ne faut pas voir dans la compilation la définition de VM.
Après on a peut-être une définition des machines virtuelles un peu différente, vu ton affirmation.
Très certainement.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
C'est à ça que sert l'introspection, à enterrer 6 pieds sous terre ces foutus .h :)
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
On a pas la même définition d'une VM c'est tout.
C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.
est une pure expérience du C.
Une pure expérience du code machine, dont les instructions manipulent des tailles de données différentes sur x86 et sur x64, ce qui conduit un langage qui définit une très faible abstraction comme le C a exposé ces différences dans les types primitifs.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Sauf que tu peux mettre 4. Le langage n'offre aucune garantie et le programmeur peut se louper. L'erreur est humaine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Là est tout le problème. CQFD.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
C'est exactement le même type de risque, le même type de protection.
Quand C# est sorti, c'était vraiment je refais un Java purement MS...
Depuis le départ, .NET propose plusieurs langages ce qui en fait une plateforme différente dans l'esprit.
ben non, c'est standardisé aujourd'hui.
Comme C# ca tombe bien.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Ca c'est ta définition réductrice de VM. Pour moi une VM est tout ce qui constitue une abstraction de la machine. Quand tu proposes un peu d'introspection comme le fait C++, c'est quelque part une VM. Beaucoup plus light qu'une VM de type .NET ou Java parcqu'offrant beaucoup moins de services, on est d'accord.
En plus aujourd'hui, il y a mini 2 coeurs à disposition.
Les perfs sont bien meilleurs avec 2 threads qu'avec 2 processus, à plus forte raison avec 2 vrais coeurs.
M ! Ada comme toutes les langages t'offre une abstraction statique, qui est traduit par le compilateur. Une VM le fera en plus à la volé.
Tu vois moi aussi je peux le dire : n'importe quoi.
mono me permet de compiler directement en code natif mon code C# comme le fait ton compilateur ADA.
Un compilateur comme OCaml permet de faire également les 2.
compilé et VM sont 2 notions différentes.
C'est évident et Ada pond du code machine ! (essaye gnat)
mono et .NET aussi dit donc.
si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.
Il optimise au sein d'une méthode mais il va sûrement pas casser la sémantique des classes/méthodes/héritage, ce qui rendrait toute interopérabilité et l'introspection impossible.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
On est d'accord, mais le problème vient plus de la multiplicité de code exposé. Y'a beaucoup trop de code "non fiable" qui se retrouve à tourner dans nos navigateurs.
de la poudre verte.
C'est mon quotidien cette poudre.
les entrées/sorties standard, les pipes et autres named pipe... et des shells, des utilitaires et autres langages de script à foison...
Gni ? Rapport ?
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Et surtout totalement propriétaire pour une architecture matérielle donnée. L'OS tout seul ne peut rien faire.
C'est une protection hardware, pas software, l'OS ne fait qu'exposer cette protection.
Une VM peut faire cette protection de manière software indépendamment de l'hardware parcqu'elle propose justement une autre vu que le code machine.
C'est la différence entre une garantie donné par une barrière comme le hardware, et une "gestion" qui est _censé_ être bien faite.
En pratique, les 2 sont complémentaires, et la gestion hardware est beaucoup trop rigide et pas assez précise (granularité : processus).
Et puis quand tu veux faire du portable (style applet), ben t'as pas le choix d'utiliser une abstraction.
Ce que tu décris, cela s'appelle de la gestion de processus
Non, ca s'appel la gestion de processus au niveau OS parcque c'est le seul cloisonnement que l'OS sait offrir.
Ca s'appel pas comme ca au niveau VM parcque ca se gère pas au niveau processus mais au niveau instruction (chaque instruction est contrôlable et contrôlée).
Là est toute la différence.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
A condition que tu respectes strictement les conventions de codage imposée par glib. A défaut d'avoir un langage qui offre la fonctionnalité, ils fournissent une lib en partant du principe que le programmeur va respecter les conventions que le compilateur est incapable de vérifier car ce n'est pas dans sa sémantique.
Oui et alors ? C++ ne tourne pas sur une VM et dispose de la gestion d'exception en quoi faut-il une VM pour ça ?
Ben si, en définissant les exception et typeid, C++ défini une VM. De base le code machine ne te propose pas ce genre de mécanisme, le compilateur est obligé d'ajouter du code et le langage de fournir une abstraction pour gérer celà, bref une VM.
tout les langages formels.
qui définissent tous une VM.
comme le javascript ?
javascript fourni au développeur un environnement virtuel d'exécution qui n'a rien à voir avec du code machine, bref une VM.
Dans une certaine limite, je crois qu'il avait essayé de faire tourner du Fortran dans .NET et ils ont vite laisser tomber.
Ca existe toujours.
Sinon, les autres langages passe par les API C, mais c'est vrai que c'est lourd.
Et encore, c'est qu'une convention qu'heureusement la plupart respecte... Mais tu retrouves d'autre problème comme le format des bibliothèques qui diffèrent d'un OS à l'autre par exemple.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Jor. A quoi sert le sizeof ?
A quoi servent les options -m32 and -m64 de GCC ? Pourquoi quand je change d'option mon sizeof me rend pas la même chose ? 4 et 8 dans l'autre ?
Exacte mais est-ce tellement génant ?
Oui, celà demande beaucoup de ressources supplémentaires :
- des développeurs qui s'assurent que le code est "plateforme agnostic" et "compilateur agnostic"
- des packageurs qui doivent prévoir autant de packages
- de l'espace disque pour stocker toutes ces variantes (regarde Debian)
- des ressources machines pour compiler tout ça.
Sans parler du fait que certains ne 's'enmerde' pas à faire tout ce boulot (pas de temps ou soft pas assez populaire pour qu'un mec le fasse à ta place) et tu te retrouves à devoir faire le travail toi même, parfois t'es un simple utilisateur et t'as autre chose à foutre.
Oui c'est génant je crois.
et que cela ne couvre rien des problèmes de haut niveau comme les "SQL injection", le X-site-scritping, et autre.
Effectivement, ca ne protège pas non plus ta grand mère au carrefour quand elle traverse. Mais ce que tu dis n'est pas faux.
Enfin, tout les langage formels quoi :)
Qui définissent tous une VM :) C'est parcqu'il y a production direct de code machine qu'il n'y a pas de VM. Une VM est une abstraction par nature virtuelle, in fine c'est toujours du code machine qui s'exécute.