Python a un compilateur! Vous ne le remarquez simplement pas car il s'exécute automatiquement. Vous pouvez cependant dire qu'il est là: regardez les fichiers .pyc
(ou .pyo
si l'optimiseur est activé) générés pour les modules que vous utilisez import
.
En outre, il ne se compile pas dans le code de la machine native. Au lieu de cela, il compile en un code d'octet utilisé par une machine virtuelle. La machine virtuelle est elle-même un programme compilé. Ceci est très similaire à la façon dont Java fonctionne; si similaire, en fait, qu'il existe à la place une variante Python ( Jython ) qui se compile en code octet de la machine virtuelle Java! Il y a aussi IronPython , qui se compile en CLR de Microsoft (utilisé par .NET). (Le compilateur de code d'octet Python normal est parfois appelé CPython pour le dissocier de ces alternatives.)
C ++ doit exposer son processus de compilation car le langage lui-même est incomplet; il ne spécifie pas tout ce que l'éditeur de liens doit savoir pour construire votre programme, ni ne peut spécifier les options de compilation de manière portable (certains compilateurs vous permettent d'utiliser #pragma
, mais ce n'est pas standard). Vous devez donc faire le reste du travail avec des makefiles et éventuellement auto hell (autoconf / automake / libtool). C'est vraiment juste un souvenir de la façon dont C l'a fait. Et C l'a fait de cette façon parce qu'il a rendu le compilateur simple, ce qui est l'une des principales raisons pour lesquelles il est si populaire (n'importe qui pouvait lancer un simple compilateur C dans les années 80).
Certaines choses qui peuvent affecter le fonctionnement du compilateur ou du lieur mais qui ne sont pas spécifiées dans la syntaxe C ou C ++:
- résolution des dépendances
- exigences de la bibliothèque externe (y compris l'ordre des dépendances)
- niveau d'optimisation
- paramètres d'avertissement
- version de spécification de langue
- mappages de l'éditeur de liens (quelle section va où dans le programme final)
- architecture cible
Certains d'entre eux peuvent être détectés, mais ils ne peuvent pas être spécifiés; par exemple, je peux détecter avec quel C ++ est utilisé __cplusplus
, mais je ne peux pas spécifier que C ++ 98 est celui utilisé pour mon code dans le code lui-même; Je dois le passer comme indicateur au compilateur dans le Makefile, ou faire un réglage dans une boîte de dialogue.
Bien que vous puissiez penser qu'un système de "résolution de dépendance" existe dans le compilateur, générant automatiquement des enregistrements de dépendance, ces enregistrements indiquent uniquement les fichiers d'en-tête utilisés par un fichier source donné. Ils ne peuvent pas indiquer quels modules de code source supplémentaires sont nécessaires pour se lier à un programme exécutable, car il n'existe aucun moyen standard en C ou C ++ d'indiquer qu'un fichier d'en-tête donné est la définition d'interface pour un autre module de code source par opposition à juste un tas de les lignes que vous souhaitez afficher à plusieurs endroits afin de ne pas vous répéter. Il existe des traditions dans les conventions de dénomination des fichiers, mais elles ne sont ni connues ni appliquées par le compilateur et l'éditeur de liens.
Plusieurs d'entre eux peuvent être définis à l'aide #pragma
, mais ce n'est pas standard, et je parlais de la norme. Toutes ces choses pourraient être spécifiées par une norme, mais n'ont pas été dans l'intérêt de la compatibilité descendante. La sagesse qui prévaut est que les makefiles et les IDE ne sont pas cassés, alors ne les corrigez pas.
Python gère tout cela dans le langage. Par exemple, import
spécifie une dépendance de module explicite, implique l'arborescence des dépendances et les modules ne sont pas divisés en en-têtes et fichiers sources (c'est-à-dire interface et implémentation).