J'ai lu un livre qui faisait référence à .net CLR comme machine virtuelle ? Quelqu'un peut-il justifier cela? Quelle est la raison pour laquelle nous avons besoin du concept de machines virtuelles sur certaines plateformes de développement?
N'est-il pas possible de développer un framework natif [un sans machine virtuelle] entièrement orienté objet et aussi puissant que .net?
Le livre qui fait référence à CLR comme machine virtuelle est " Professional .Net Framework 2.0 ".
Il y a beaucoup de fausses idées ici. Je suppose que vous pourriez penser .Net comme une machine virtuelle si tu le voulais vraiment, mais regardons comment le .Net Framework gère votre code. Le scénario typique ressemble à ceci
Il y a quelques points importants ici, mais le grand est que à aucun moment aucun code jamais interprété. Au lieu de cela, vous pouvez le voir dans l'étape 5 qu'il est compilé en code natif. Cette énorme différence de chargement dans une machine virtuelle, pour plusieurs raisons:
Je suppose que vous pourriez appeler cela une machine virtuelle, dans le sens de la Gigue résumés loin les détails de la machine réelle de la part du développeur. Personnellement, je ne pense pas que c'est vraiment bon, parce que pour beaucoup de gens, une machine virtuelle implique un temps d'exécution de l'abstraction à l'écart de code natif pour .Net les programmes n'existent pas.
Un autre point important concernant l'ensemble de ce processus qui distingue vraiment à part une "machine virtuelle" de l'environnement, c'est que c'est seulement à la typique du processus. Si vous le voulez vraiment, vous pouvez pré-compiler un .Net de l'assemblée avant de la distribution et de déployer du code natif directement à l'utilisateur final (indice: c'est plus lente en moyenne sur la durée de vie du programme, parce que vous perdez de la machine-optimisations spécifiques). Bien sûr, vous avez encore besoin de la .Net runtime installé, mais à ce point c'est vraiment pas très différente de toute autre exécution de l'API, c'est plus une collection dll avec une belle API, vous pouvez lier contre, comme vous avez pu le VB ou C temps de fonctionnement de Microsoft est également livré avec Visual Studio. Ce genre de faut de l'IL de l'image, rendant la VM moniker beaucoup plus difficile à justifier. (Je dis "genre de", car IL est toujours déployé et utilisé pour vérifier le même code, mais il n'est jamais lui-même touché pour l'exécution).
Je pense que le plus révélateur chose, cependant, est l'absence d'une VM processus. Lorsque vous exécutez votre application, il n'y a pas de commune "bac à sable" processus qui s'exécute. A comparer avec Java, où si vous ouvrez le gestionnaire des tâches lorsqu'un programme est en cours d'exécution, vous verrez un processus spécifiquement pour la machine virtuelle Java, et l'application du processus réel est un fil à l'intérieur de l'espace créé par la machine virtuelle. Dans .Net, vous voyez l'application du processus dans le gestionnaire des tâches de Windows directement.
En résumé: on pourrait dire qu'IL + CLR + JIT, ensemble, faire en quelque sorte une machine virtuelle. Personnellement, je ne le pense pas, mais je ne vais pas discuter avec vous si vous croyez que. Le point que je veux faire, c'est que lorsque vous dites à quelqu'un qu' .Net s'exécute dans une machine virtuelle avec aucune autre explication, l'idée que vous communiquez à personne, elle est "interprété bytecode dans un processus hôte." Et c'est tout simplement faux.
Semblable à la Machine Virtuelle Java (JVM), l' .net CLR est un byte-code de l'interprétation de la machine virtuelle.
La JVM interprète des programmes qui contiennent java byte codes et les .net CLR interprète des programmes qui contiennent ce que Microsoft appelle "le Langage Intermédiaire" des instructions. Il y a des différences entre ces octets de codes, mais les machines virtuelles sont similaires et aspire à fournir des fonctionnalités similaires.
Ces deux machine virtuelle implémentations ont la possibilité de compiler leur entrée bytecode pour le langage machine de l'ordinateur qu'ils sont en cours d'exécution sur. Ceci est appelé "Juste À Temps de Compilation JIT ()" et le code de sortie produite est appelée "JIT code." Parce que le JIT code contiennent des séquences d'instructions en langage machine du PROCESSEUR de l'ordinateur, ce code est parfois désigné comme "natifs" du code.
Cependant, JIT code est qualitativement et quantitativement différente de code natif, comme expliqué ci-dessous. Pour cette raison, cet article considère JIT code pour être rien de plus qu'une implémentation native de la Machine Virtuelle lors de l'exécution d'un particulier bytecode programme.
Une caractéristique que ces deux Machines Virtuelles (VMs) aspire à fournir est de la sécurité dans le formulaire de prévenir un certain nombre de dangereuses erreurs de programmation. Par exemple, le titre de ce forum d'un site web, stackoverflow, est inspiré par un tel type de dangereux erreur qui est possible en code natif.
Afin d'assurer la sécurité et la sécurité de l'exécution, le VMs de mettre en œuvre la sécurité de type à la "Machine Virtuelle" de niveau. Les affectations de mémoire virtuelle sont nécessaires pour stocker le type de données qui est tenue à cet emplacement de la mémoire. Par exemple, si un nombre entier est poussé sur la pile, il n'est pas possible de la pop un double de la pile. C-style "unions", sont interdites. Les pointeurs et l'accès direct à la mémoire sont interdites.
Nous ne pouvions pas obtenir les mêmes avantages en imposant un langage orienté objet-cadre sur les développeurs si le résultat est un fichier binaire natif comme un fichier EXE. Dans ce cas, nous ne serions pas en mesure de distinguer entre les binaires générés à l'aide du cadre et des Exe généré par un utilisateur malveillant employant d'autres sources que le cadre.
Dans le cas de la VMs, le type de sécurité est appliquée au "niveau le plus bas" que le programmeur est autorisé à accéder. (En négligeant pour l'instant qu'il est possible d'écrire géré en code natif, ce qui est.) Par conséquent, aucun utilisateur ne rencontrerez une application qui effectue l'une des opérations dangereuses qui nécessitent un accès direct à la mémoire des emplacements et des pointeurs.
Dans la pratique, l' .net CLR une manière d'écrire du code natif qui peut être appelé par .net "géré" du code. Dans ce cas, la charge est sur le code natif à l'auteur de ne pas faire du pointeur et de la mémoire des erreurs.
Comme la JVM et .net CLR effectuer la compilation JIT, soit VM crée en fait un natif binaire compilé à partir du bytecode fourni. Cette "JIT code" effectue plus rapidement que la VM est l'interprète de l'exécution, parce que même le langage machine code produit par JIT contient toutes les VM de sécurité vérifie que l'ordinateur virtuel effectuer. En conséquence, l'équipe de code de sortie n'est pas aussi rapide que le code natif qui seraient normalement pas contenir de nombreux au moment de l'exécution des contrôles. Toutefois, cette vitesse de la performance inconvénient est échangé pour une amélioration de la fiabilité, y compris la sécurité; en particulier, l'utilisation de non initialisé de stockage est empêché, de sécurité du type de missions est appliquée, de la portée de la vérification est effectuée (donc pile et tas dépassements de la mémoire tampon empêché), objet des durées de vie sont gérées par la collecte des ordures, l'allocation dynamique est de type sécurisé. Un environnement d'exécution de ce moment de l'exécution comportement de contrôle, la mise en œuvre de la spécification d'une machine virtuelle et n'est guère plus qu'un langage machine de la réalisation d'une machine virtuelle.
La "Machine Virtuelle" partie se réfère au fait que .NET code est compilé en EXE et DLL comme "Intermédiaire" de l'Assemblée de la langue (IL) pour s'exécuter sur une machine virtuelle, par opposition à réel CPU langage d'assemblage. Puis, au moment de l'exécution de l'ILM est converti en CPU réel de l'assemblée pour l'exécution (appelé Just-in-time ou JIT compiler).
Bien sûr, vous pourriez écrire un .NET compilateur de sorte qu'il serait compilé dans l'UC de l'assemblée de la langue au lieu de l'IL. Cependant, ce ne serait pas portable pour tous les Cpu - vous auriez à compiler une version différente pour chaque système d'exploitation/PROCESSEUR paire. Mais en compilant dans ILM, vous laissez la "Machine Virtuelle" gérer le PROCESSEUR et l'OS de choses spécifiques.
L'avantage du CLR est la liberté d'écrire du code dans le langage de programmation choisi par le développeur, car le code sera compilé en CLR avant d'être interprété en appels natifs. Le framework .NET utilise cette compilation JIT pour traiter tout uniformément et produire des programmes qui fonctionnent pour la plate-forme déployée, qui est absent des langages compilés.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
