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.
Cordialement.

Cchristian.

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.

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

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.

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é. Cordialement.

Cchristian.

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 ^^