Langues gérées vs différence de langue compilée?


18

Je suis confus lorsque les gens essaient de faire une distinction entre les langues compilées et les langues gérées. Par expérience, je comprends que la plupart considèrent les langages compilés comme C, C ++ tandis que les langages gérés sont Java, C # (Il y en a évidemment plus, mais ce ne sont que quelques exemples). Mais quelle est exactement la différence fondamentale entre les deux types de langues?

Je crois comprendre que tout programme, quelle que soit la langue que vous utilisez, est essentiellement «compilé» en un code machine de bas niveau qui est ensuite interprété, de sorte que les langues gérées constituent un sous-ensemble des langues compilées (c'est-à-dire que toutes les langues gérées sont langues compilées mais pas l'inverse)?


2
ce terme est inventé par Microsoft, au sens strict, Java est également géré. Presque dans tous les cas , nous pouvons penser des langues gérées comme d'un sous - ensemble de ce qui compiles.Also, cela, je crois est lié - programmers.stackexchange.com/questions/72446/...
shabunc

Notez qu'il y a une énorme différence entre un langage qui compile (statiquement) le code en quelque chose de plus gérable par la machine avant l'exécution (comme Java) et un qui le fait à l'exécution (comme Python). Une différence majeure est que la compilation statique avant l'exécution donne au compilateur la possibilité de faire quelques optimisations qui peuvent entraîner des améliorations de vitesse importantes (comme JIT de Java, réorganiser le code pour la prédiction de branche, etc.).
Shivan Dragon

6
@ShivanDragon, un "langage" ne compile rien. Sa mise en œuvre le fait. Et vous pouvez compiler Python statiquement (voir PyPy ou IronPython par exemple). OTOH, il est vraiment difficile de le faire efficacement avec un langage typé dynamiquement (recherchez "traçage JIT", "interprétation abstraite", etc.)
SK-logic

@ SK-logic: d'accord, j'ai dit un méchant. Je voulais me référer à la plateforme, pas à la langue.
Shivan Dragon

@shabunc En fait, je dirais que Compiled est un sous-ensemble de Managed. Un langage géré peut faire tout ce qu'un langage compilé peut faire (à pratiquement la même vitesse), et plus encore, car un langage géré peut être compilé. Afin de donner à C les fonctionnalités d'un langage managé, vous devez créer une "VM" et en faire un langage managé.
Bill K

Réponses:


47

La différence n'est pas entre "compilé" et "géré", ce sont deux axes orthogonaux. Par «géré», ils signifient normalement la présence d'une gestion de mémoire récupérée et / ou la présence d'une infrastructure de machine virtuelle. Les deux n'ont absolument rien à voir avec la compilation et tout ce que les gens jugent contraire.

Toutes ces «différences» sont assez floues, artificielles et non pertinentes, car il est toujours possible de mélanger la mémoire gérée et non gérée en un seul runtime, et une différence entre compilation et interprétation est également très vague.


2
C'est ce que j'avais à l'esprit, mais j'ai rencontré beaucoup de gens qui continuent à faire cette distinction. Merci pour la réponse claire.
l46kok

Le code managé signifie avoir un langage intermédiaire pour être pris en charge quel que soit l'environnement d'exécution sur lequel vous exécutez au moment de l'exécution, non? Donc, ce langage intermédiaire (disons bytecode) doit être produit par un compilateur. IMO, qui couple un peu le code "managé" et le concept de "compilation". Cependant, si le langage est "compilé", cela ne montre pas qu'il donne un code managé (ie. C ++ vs Java)
zgulser

@zgulser, non, les langues intermédiaires sont orthogonales. Géré signifie avoir un GC intégré au runtime du langage. Par exemple, le runtime OCaml est "géré", bien qu'il compile directement en natif.
SK-logic

8

Pour citer Wikipedia:

Le code managé est un terme inventé par Microsoft pour identifier le code source d'un programme informatique qui nécessite et ne s'exécutera que sous la gestion d'une machine virtuelle Common Language Runtime (résultant en bytecode).

Le code managé a besoin d'un runtime (comme le .NET CLT) pour s'exécuter.


5
Le code managé n'a rien à voir avec un framework. Il a besoin d'un runtime qui gère la mémoire.
Oded

Peut-être que ma formulation est un peu décalée, mais le framework .NET n'est-il pas réellement un "runtime de langage commun"?
janvdl

3
Non. In inclut le CLR, mais il inclut également les bibliothèques de classes de base, la spécification IL et plus encore.
Oded

4

Je pense qu'il y a une distinction à faire, mais ce n'est pas nécessairement entre «compilé» et «géré». Ce ne sont pas des opposés; un langage peut être compilé et non géré, ou interprété (non compilé) et géré, ou les deux, ou même ni l'un ni l'autre.

Un langage "compilé" est simplement un langage dans lequel il y a une étape qui transforme le code source écrit par le développeur en un "bytecode" plus régulier qui est exécuté par la machine. La «machine» peut être le processeur réel, ou une «machine virtuelle» qui effectue des opérations supplémentaires sur les bytecodes pour les traduire en instructions machine «natives». L'antonyme d'un langage "compilé" est un langage "interprété", dans lequel le code source est transformé en instructions de bytecode au moment de l'exécution, ligne par ligne au fur et à mesure de leur exécution, sans étape de compilation. Un hybride entre eux est "jitting", de "JIT" (Just In Time), qui est généralement interprété comme une étape unique par la machine exécutante;

Un langage "géré" est un langage conçu pour produire des programmes qui sont consommés dans un environnement d'exécution spécifique, qui comprend presque toujours un interpréteur de bytecode; une "machine virtuelle" qui prend le code du programme et effectue une transformation supplémentaire spécifique à la machine ou à l'environnement. L'environnement peut également inclure la gestion de la mémoire, comme un «garbage collector» et d'autres fonctionnalités de «sécurité» destinées à maintenir le programme dans son «bac à sable» d'espace et d'outils, mais ces fonctionnalités ne sont pas le seul domaine des runtimes «gérés» . Pratiquement tous les langages interprétés peuvent être considérés comme gérés, car ils nécessitent que l'interpréteur s'exécute sous les lignes de code "utilisateur" en cours d'exécution. De plus, les langages JVM et .NET (Java, Scala, C #, VB, F #, IronWwhat) sont compilés dans un langage intermédiaire ou IL, qui est superficiellement similaire dans sa forme et sa fonction à un langage d'assemblage binaire, mais n'adhère pas à 100% à un ensemble d'instructions "natif". Ces instructions sont exécutées par la JVM ou par le CLR de .NET, qui les traduit efficacement en instructions binaires natives spécifiques à l'architecture CPU et / ou au système d'exploitation de la machine.

Ainsi, les langues peuvent généralement être décrites comme "compilées" ou "interprétées", et comme "non gérées" (ou "natives") et "gérées". Il existe des langages qui peuvent être décrits comme n'importe quelle combinaison de ceux-ci, à l'exception d'un éventuel "natif interprété" (qui ne serait vrai que pour les opcodes hexadécimaux écrits à la main, où ce qui est écrit par le développeur est ce qui est exécuté); si vous considérez la couche d'interprétation comme un "runtime" (ce qui est facile à argumenter et difficile à argumenter), alors tous les langages interprétés sont "gérés".

Si vous voulez devenir technique, presque tous les programmes ciblant un OS multitâche de nos jours sont "gérés"; le système d'exploitation créera une "machine virtuelle" pour chaque programme en cours d'exécution, dans laquelle le programme pense (ou du moins n'a pas besoin de savoir le contraire) que c'est la seule chose en cours d'exécution. Le code peut effectuer des appels en lui-même et vers d'autres bibliothèques référencées comme si ce programme était la seule chose chargée en mémoire; de même, les appels d'allocation de RAM et d'autres mémoires plus élevées pour stocker et manipuler des données et des dispositifs de contrôle sont codés comme si toute l'architecture de la mémoire était disponible. La machine virtuelle (et le système d'exploitation derrière elle) traduit ensuite divers pointeurs de mémoire vers l'emplacement réel du programme, ses données et les crochets vers les pilotes de périphérique, etc. Cela se fait le plus souvent en appliquant un décalage de mémoire (chaque machine virtuelle obtient un bloc de 2 Go. ou quoi que ce soit de la mémoire, à partir de l'adresse X que le programme peut traiter comme si ce X était l'adresse 0) et en tant que telle est très bon marché, mais il y a d'autres choses dont le noyau du système d'exploitation est responsable, telles que la planification des processus et la communication interprocessus, qui sont plus difficile à gérer. Cependant, ce modèle de base n'est généralement pas considéré comme "géré", car le programme n'a pas besoin de savoir qu'il est exécuté par une machine virtuelle et est souvent toujours responsable de garder sa mémoire allouée "propre". Un programme qui a été conçu pour être exécuté sur la ligne de commande MS-DOS peut être exécuté sur des systèmes d'exploitation Windows plus récents qui n'ont même plus l'environnement MS-DOS sous eux; le programme reçoit à la place un environnement de "console virtuelle", et à condition qu'il n'essaye pas de quitter ce "bac à sable"


"Les langues peuvent généralement être décrites comme" compilées "ou" interprétées "" - Non, elles ne le peuvent pas. La compilation et l'interprétation sont des traits caractéristiques des compilateurs et interprètes et non des langues. Le terme «langage compilé» n'a même pas de sens. Si l'anglais était une langue tapée, ce serait une erreur de frappe.
Jörg W Mittag

2
On trouve généralement des compilateurs et des interprètes qui compilent et interprètent des dialectes très spécifiques de langues qui sont conçues pour subir soit une compilation soit une interprétation. Personne ne compile le code source JavaScript que je connaisse et personne n'interprète C #. Les langues sont conçues pour être consommées d'une manière ou d'une autre. En tant que tel, il est généralement acceptable de faire référence à la langue elle-même comme «compilée» ou «interprétée» car l'environnement complet dans lequel la langue est utilisée implique l'une de ces deux étapes.
KeithS


en.wikipedia.org/wiki/Interpreted_language - "Théoriquement, n'importe quelle langue peut être compilée ou interprétée, donc cette désignation est appliquée uniquement en raison de la pratique d'implémentation courante et non d'une propriété essentielle d'une langue."
KeithS

@KeithS, wikipedia n'est pas presque parfait. Le fait qu'un article existe pour un certain terme invalide ne rend pas ce terme plus valable. Oui, les langues sont toujours conçues avec un certain mode d'exécution à l'esprit, mais il est toujours contre-productif de les qualifier de «compilées» ou «interprétées» uniquement sur la base de l'intention de leurs concepteurs. Et, comme pour une interprétation, il est vraiment difficile de trouver un "interprète" approprié de toute façon. Tcl est probablement le dernier du genre. Tous les autres soi-disant «interprètes» sont en fait des compilateurs.
SK-logic

2

Langage géré en termes simples, c'est un langage de haut niveau qui dépend des services fournis par un environnement d'exécution à exécuter, comme le service de collecte des ordures, c'est pourquoi il est appelé géré en général, mais ce n'est pas le seul service qu'il utilise , et certains de ces services sont security services, exception handling, standard types, il utilise Common Language Run-time CLRpour exécuter, comme dans les langages .Net ou un environnement virtuel comme Java qui utilise `Java Virtual Machine JVM.

Unmanaged Language est un langage de bas niveau exécutable directement par le système d'exploitation sans avoir besoin de services d'exécution virtuels ou d'un langage intermédiaire.Ces langages comme le C, C++code non managé produit par ces langages utilisent des routines de bibliothèque liées dynamiquement au système d'exploitation pour obtenir le code à exécuter appelé DLL (Dynamic Link Libraries), le code non managé accède directement à la mémoire, c'est pourquoi il est plus rapide que le code managé, mais à moins que vous ne construisiez un pilote matériel ou un jeu vidéo sophistiqué, vous ne voulez pas vraiment utiliser des langages non managés comme il peut être dangereux de travailler avec en particulier avec des développeurs inexpérimentés comme l'état du rôlewith great power comes great responsibility, et c'est pourquoi les langages gérés existent pour aider les développeurs à produire du code extensible sans plonger dans le bas du système, mais vous pouvez toujours créer du code mixte si vous en avez besoin, ces articles expliquent tout:

Présentation de l'interopérabilité du code managé / non managé

Exemple: mélange de code C ++ non géré, C ++ / CLI et C #

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.