Avantages/Inconvénients des Compilateurs
Fermé
luna
-
23 mars 2008 à 15:14
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 - 24 mars 2008 à 18:01
Mahmah Messages postés 496 Date d'inscription lundi 17 septembre 2007 Statut Membre Dernière intervention 22 juin 2010 - 24 mars 2008 à 18:01
A voir également:
- Avantages/Inconvénients des Compilateurs
- Texte argumentatif sur les avantages et les inconvénients du téléphone portable ✓ - Forum Mobile
- Quelle est les avantages de telephone portable - Forum Hotmail / Outlook.com
- Téléphone portable avantage ou inconvénient - Forum Mobile
- Avantages et inconvenients du telephone mobil - Forum Mobile
- Conclusion sur les avantages et les inconvénients de linternet ✓ - Forum Réseaux sociaux
6 réponses
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
23 mars 2008 à 20:04
23 mars 2008 à 20:04
Bonjour,
Quelques réflexions en complément à ce qui est cité dans le post :
LA COMPILATION (+ EDITION DES LIENS ?) : (dans un vision : langage portable conçu dans une optique "universelle", tel COBOL)
- Permet dans un premier temps de localiser les erreurs de syntaxe et quelquefois même certaines erreurs de logique => donc pas de surprise de cet ordre au moment de l'exécution. La phase exécutable ne sera pas créée tant qu'il subsiste une ou plusieurs erreurs blocantes.
- Associée à la phase d'édition des liens (link edit) la compilation et plus précisément, ces deux phases logiquement indissociables et caractéristiques d'un "langage compilé", permettent de mieux connaître et de mieux contrôler la taille des unités d'exécution. (important en optique grand système/exploitation => taux d'occupation de la machine calculé au plus juste => répartition et planification des tâches.) .
- Autorise une rapidité d'exécution sans commune mesure avec celle des programmes écrits en langage interprétés.
- Les options qui accompagnent le compilateur (options de compilation) et celles qui accompagnent l'éditeur de liens (options de link édit) amènent une souplesse supplémentaire relative au paramètrage des conditions d'exécution de chaque programme.
- Permet une duplication implicite des fonctions exécutables, le code source n'est solicité qu'à la phase de compilation/link edit.
LES LANGAGES INTERPRETES (INTERPRETEUR)
- Permet de tester "en mode immédiat" et de manière graduelle, progressive les programmes en cours d'élaboration.
- Ne sont donc pas subordonnés à la "contrainte" des phases de compilation/link-edit'. En contrepartie une séquence d'instructions peut ainsi échapper à toutes investigations (contrôles de syntaxe évoqués plus haut) en phase de test pour peu que les jeux d'essais soient incomplets.
- Se caractérisent par une lenteur d'exécution comparativement aux programmes compilés.
Il doit y avoir d'autres arguments qui m'échappent, attendons d'autres réponses,
L'idéal est de disposer d'un langage "compilé et interprété", c'est ce qui caractérise bien souvent les langages procéduraux.
Quelques réflexions en complément à ce qui est cité dans le post :
LA COMPILATION (+ EDITION DES LIENS ?) : (dans un vision : langage portable conçu dans une optique "universelle", tel COBOL)
- Permet dans un premier temps de localiser les erreurs de syntaxe et quelquefois même certaines erreurs de logique => donc pas de surprise de cet ordre au moment de l'exécution. La phase exécutable ne sera pas créée tant qu'il subsiste une ou plusieurs erreurs blocantes.
- Associée à la phase d'édition des liens (link edit) la compilation et plus précisément, ces deux phases logiquement indissociables et caractéristiques d'un "langage compilé", permettent de mieux connaître et de mieux contrôler la taille des unités d'exécution. (important en optique grand système/exploitation => taux d'occupation de la machine calculé au plus juste => répartition et planification des tâches.) .
- Autorise une rapidité d'exécution sans commune mesure avec celle des programmes écrits en langage interprétés.
- Les options qui accompagnent le compilateur (options de compilation) et celles qui accompagnent l'éditeur de liens (options de link édit) amènent une souplesse supplémentaire relative au paramètrage des conditions d'exécution de chaque programme.
- Permet une duplication implicite des fonctions exécutables, le code source n'est solicité qu'à la phase de compilation/link edit.
LES LANGAGES INTERPRETES (INTERPRETEUR)
- Permet de tester "en mode immédiat" et de manière graduelle, progressive les programmes en cours d'élaboration.
- Ne sont donc pas subordonnés à la "contrainte" des phases de compilation/link-edit'. En contrepartie une séquence d'instructions peut ainsi échapper à toutes investigations (contrôles de syntaxe évoqués plus haut) en phase de test pour peu que les jeux d'essais soient incomplets.
- Se caractérisent par une lenteur d'exécution comparativement aux programmes compilés.
Il doit y avoir d'autres arguments qui m'échappent, attendons d'autres réponses,
L'idéal est de disposer d'un langage "compilé et interprété", c'est ce qui caractérise bien souvent les langages procéduraux.
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
23 mars 2008 à 20:51
23 mars 2008 à 20:51
Bonjour,
Un avantage pour l'interprèté: Il marchera sur du 32 et 64 bits sans distribuer 2 programmes ainsi que sur tous les OS ayant un interprète.
Ne parleras-tu pas des langages mixtes ? Compilés puis interprétés... comme Java ou C#...
M.
Un avantage pour l'interprèté: Il marchera sur du 32 et 64 bits sans distribuer 2 programmes ainsi que sur tous les OS ayant un interprète.
Ne parleras-tu pas des langages mixtes ? Compilés puis interprétés... comme Java ou C#...
M.
Bonjour,
merci pour vos réponses.
J'hésite à parler de l'édition des liens, d'une part parce que je n'y connais rien et d'autre part parce que c'est un travail de vulgarisation : je dois expliquer les compilateurs à mon prof en 20 minutes. (pour vous donner une idée de la tache, il ne sait pas ce que c'est qu'un éditeur de texte! J'ai du lui dire que c'était une sorte de word car même le bloc note il ne connaissait pas!)
Mahmah, je n'ai pas trop (du tout) compris ta réponse : c'est quoi la distribution de 2 programmes? Je n'ai jamais entendu parler de ça.
Pour la même raison que celle des liens, j'hésite à parler des langages compilés et interprétés.
Encore merci
merci pour vos réponses.
J'hésite à parler de l'édition des liens, d'une part parce que je n'y connais rien et d'autre part parce que c'est un travail de vulgarisation : je dois expliquer les compilateurs à mon prof en 20 minutes. (pour vous donner une idée de la tache, il ne sait pas ce que c'est qu'un éditeur de texte! J'ai du lui dire que c'était une sorte de word car même le bloc note il ne connaissait pas!)
Mahmah, je n'ai pas trop (du tout) compris ta réponse : c'est quoi la distribution de 2 programmes? Je n'ai jamais entendu parler de ça.
Pour la même raison que celle des liens, j'hésite à parler des langages compilés et interprétés.
Encore merci
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
24 mars 2008 à 12:05
24 mars 2008 à 12:05
Puisque l'on parle de Word:
MS Office 64 Certes cette version va améliorer deux des logiciels et permettre de vendre des nouvelles licences, mais quand un OS 64 bits a bien du mal à faire tourner les applications 32 bits vendues par la même société et bien il vaut mieux distribuer les versions 32 et 64 bits de ses logiciels.
Je ne sais pas ce qu'il en est sous linux 64, je ne suis pas sûr qu'il existe une couche de retro-compatibilité vers le 32 bits. Par contre il semblerait qu'une solution autre soit privilégiée... recompiler. Ce qui revient au même finalement.
Le fait est que lorsqu'un OS 64 tombe sur un programme qui a des types qui n'avait pas la même taille en 32 bits ça coince car le code est figé alors que l'interpréteur n'a pas de problème de compréhension. (Ce qui ne veut pas dire que le programme marchera sans bug pour autant, mais il s'exécutera) A vérifier peut-être aussi que le code n'est généré n'est même pas compréhensible directement. C'est là où avoir une
Les bugs les plus courants lors du passage 32 vers 64 sont les flags et les données stoquées. On prends une structure toute bête qui contient un int et un long, on les mets dans un fichier sur un ordi 32 bits, le hic est que la version 64 lira 32 puis 64 bits au lieu de 32 et 32 car le long a changé. Donc l'interpréteur a beau être capable d'exécuter le programme si le programmeur est un pied... Mais théoriquement le programme continue de fonctionner sans devoir fournir une version recompilée en 64 bits.
M.
MS Office 64 Certes cette version va améliorer deux des logiciels et permettre de vendre des nouvelles licences, mais quand un OS 64 bits a bien du mal à faire tourner les applications 32 bits vendues par la même société et bien il vaut mieux distribuer les versions 32 et 64 bits de ses logiciels.
Je ne sais pas ce qu'il en est sous linux 64, je ne suis pas sûr qu'il existe une couche de retro-compatibilité vers le 32 bits. Par contre il semblerait qu'une solution autre soit privilégiée... recompiler. Ce qui revient au même finalement.
Le fait est que lorsqu'un OS 64 tombe sur un programme qui a des types qui n'avait pas la même taille en 32 bits ça coince car le code est figé alors que l'interpréteur n'a pas de problème de compréhension. (Ce qui ne veut pas dire que le programme marchera sans bug pour autant, mais il s'exécutera) A vérifier peut-être aussi que le code n'est généré n'est même pas compréhensible directement. C'est là où avoir une
Les bugs les plus courants lors du passage 32 vers 64 sont les flags et les données stoquées. On prends une structure toute bête qui contient un int et un long, on les mets dans un fichier sur un ordi 32 bits, le hic est que la version 64 lira 32 puis 64 bits au lieu de 32 et 32 car le long a changé. Donc l'interpréteur a beau être capable d'exécuter le programme si le programmeur est un pied... Mais théoriquement le programme continue de fonctionner sans devoir fournir une version recompilée en 64 bits.
M.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
24 mars 2008 à 13:46
24 mars 2008 à 13:46
Bonjour,
A ton prof, il faudrait d'abord lui donner une initiation à l'informatique vue sous l'aspect développement (de programmes ou d'applications) car pour illustrer la compilation, à moins de chercher dans la vie courante des parallèles, qui restent toujours approximatifs (sur le thème de la traduction par exemple), cela ne sera pas facile pour toi.
En ce qui concerne la phase d'édition des liens elle est difficillement dissociable de la phase de compilation dans le sens ou cette dernière perdrait son intérêt (en terme de finalité) relativement à l'objectif poursuivi qui est celui de créer une phase exécutable et pour toi de (dé)montrer son utilité. En d'autre terme une compilation seule n'a d'intérêt que pour le développeur afin de vérifier la syntaxe de son programme qui à (court) terme (lorsqu'il n'y aura plus d'erreurs) passera par a phase nécessaire de "link edit" puis pourra être (enfin) exécuté.
A ton prof, il faudrait d'abord lui donner une initiation à l'informatique vue sous l'aspect développement (de programmes ou d'applications) car pour illustrer la compilation, à moins de chercher dans la vie courante des parallèles, qui restent toujours approximatifs (sur le thème de la traduction par exemple), cela ne sera pas facile pour toi.
En ce qui concerne la phase d'édition des liens elle est difficillement dissociable de la phase de compilation dans le sens ou cette dernière perdrait son intérêt (en terme de finalité) relativement à l'objectif poursuivi qui est celui de créer une phase exécutable et pour toi de (dé)montrer son utilité. En d'autre terme une compilation seule n'a d'intérêt que pour le développeur afin de vérifier la syntaxe de son programme qui à (court) terme (lorsqu'il n'y aura plus d'erreurs) passera par a phase nécessaire de "link edit" puis pourra être (enfin) exécuté.
merci mahmah pour ton complément d'info, mais il manque un bout de phrase non? : "C'est là où avoir une
" ???
cchristian :
je donnerai beaucoup d'exemples pour qu'il comprenne, mais en 20 minutes, ça va être très difficile d'expliquer les étapes de la compilation et l'edition des liens...
Je verrai bien!
En tout cas merci ^^
" ???
cchristian :
je donnerai beaucoup d'exemples pour qu'il comprenne, mais en 20 minutes, ça va être très difficile d'expliquer les étapes de la compilation et l'edition des liens...
Je verrai bien!
En tout cas merci ^^
Mahmah
Messages postés
496
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
22 juin 2010
125
24 mars 2008 à 18:01
24 mars 2008 à 18:01
En effet, pardon, "C'est là où avoir un interpréteur ou une machine virtuelle qui fait une abstraction du système d'exploitation représente aussi un grand avantage, on peut repenser simplement au domaine d'application cité dans ton premier post : internet (HTML, javascript, xml, etc) où l'on saute la barrière 32/64 bits."
Petite remarque en passant, le HTML compilé (.hlp sous Windows) ou un interpréteur pour le C ça existe aussi...
M.
Petite remarque en passant, le HTML compilé (.hlp sous Windows) ou un interpréteur pour le C ça existe aussi...
M.
