Réponses:
La différence entre le temps de compilation et le temps d'exécution est un exemple de ce que les théoriciens pointus appellent la distinction de phase . C'est l'un des concepts les plus difficiles à apprendre, en particulier pour les personnes n'ayant pas beaucoup d'expérience dans les langages de programmation. Pour aborder ce problème, je trouve utile de demander
Ce qui peut mal tourner, ce sont les erreurs d'exécution :
Il peut également y avoir des erreurs détectées par le programme lui-même:
J'y pense en termes d'erreurs et quand elles peuvent être détectées.
Temps de compilation:
string my_value = Console.ReadLine();
int i = my_value;
Une valeur de chaîne ne peut pas être affectée à une variable de type int, donc le compilateur sait avec certitude au moment de la compilation que ce code a un problème
Durée:
string my_value = Console.ReadLine();
int i = int.Parse(my_value);
Ici, le résultat dépend de la chaîne retournée par ReadLine (). Certaines valeurs peuvent être analysées en un entier, d'autres non. Cela ne peut être déterminé qu'au moment de l'exécution
.app
extension? ou cela se produit au lancement à chaque fois que l'utilisateur démarre l'application?
Temps de compilation: la période pendant laquelle vous, le développeur, compilez votre code.
Exécution: la période pendant laquelle un utilisateur exécute votre logiciel.
Avez-vous besoin d'une définition plus claire?
int x = 3/0
mais vous ne faites rien avec cette variable. Nous ne l'imprimons pas ou quoi que ce soit. Cela sera-t-il toujours considéré comme une erreur d'exécution?
( modifier : ce qui suit s'applique au C # et aux langages de programmation similaires fortement typés. Je ne sais pas si cela vous aide).
Par exemple, l'erreur suivante sera détectée par le compilateur (au moment de la compilation ) avant d'exécuter un programme et entraînera une erreur de compilation:
int i = "string"; --> error at compile-time
En revanche, une erreur comme la suivante ne peut pas être détectée par le compilateur. Vous recevrez une erreur / exception au moment de l' exécution (lorsque le programme est exécuté).
Hashtable ht = new Hashtable();
ht.Add("key", "string");
// the compiler does not know what is stored in the hashtable
// under the key "key"
int i = (int)ht["key"]; // --> exception at run-time
La traduction du code source en choses qui se passent sur l'écran [disque | réseau] peut se produire (à peu près) de deux manières; appelez-les compilation et interprétation.
Dans un programme compilé (les exemples sont c et fortran):
On dit que les choses qui se produisent dans la première étape se produisent au "moment de la compilation", les choses qui se produisent dans la deuxième étape se produisent au "temps d'exécution".
Dans un programme interprété (exemple MicroSoft basic (sur dos) et python (je pense)):
Dans ce cas, la différence entre le temps de compilation et le temps d'exécution est plus difficile à cerner et beaucoup moins pertinente pour le programmeur ou l'utilisateur.
Java est une sorte d'hybride, où le code est compilé en bytecode, qui s'exécute ensuite sur une machine virtuelle qui est généralement un interpréteur pour le bytecode.
Il existe également un cas intermédiaire dans lequel le programme est compilé en bytecode et exécuté immédiatement (comme dans awk ou perl).
Fondamentalement, si votre compilateur peut déterminer ce que vous voulez dire ou ce qu'est une valeur "au moment de la compilation", il peut coder en dur cela dans le code d'exécution. Évidemment, si votre code d'exécution doit faire un calcul à chaque fois qu'il s'exécutera plus lentement, donc si vous pouvez déterminer quelque chose au moment de la compilation, c'est beaucoup mieux.
Par exemple.
Pliage constant:
Si j'écris:
int i = 2;
i += MY_CONSTANT;
Le compilateur peut effectuer ce calcul au moment de la compilation car il sait ce qu'est 2 et ce qu'est MY_CONSTANT. En tant que tel, il évite d'effectuer un calcul à chaque exécution.
Les choses qui sont faites au moment de la compilation n'entraînent (presque) aucun coût lorsque le programme résultant est exécuté, mais peuvent entraîner un coût élevé lorsque vous générez le programme.
Plus ou moins exactement le contraire. Peu de coûts lorsque vous créez, plus de coûts lorsque le programme est exécuté.
Depuis l'autre côté; Si quelque chose est fait au moment de la compilation, il s'exécute uniquement sur votre machine et si quelque chose est en cours d'exécution, il s'exécute sur la machine de vos utilisateurs.
Un exemple où cela est important serait un type de transport d'unité. Une version au moment de la compilation (comme Boost.Units ou ma version en D ) finit par être aussi rapide que la résolution du problème avec le code natif à virgule flottante tandis qu'une version au moment de l'exécution finit par devoir regrouper des informations sur les unités qu'une valeur est à l'intérieur et effectuer des contrôles en même temps chaque opération. D'un autre côté, les versions au moment de la compilation requièrent que les unités des valeurs soient connues au moment de la compilation et ne peuvent pas traiter le cas où elles proviennent d'une entrée au moment de l'exécution.
Suite à une réponse similaire à la question précédente Quelle est la différence entre l'erreur d'exécution et l'erreur du compilateur?
Compilation / Temps de compilation / Syntaxe / Erreurs sémantiques: Les erreurs de compilation ou de temps de compilation sont des erreurs survenues en raison d'une erreur de frappe, si nous ne suivons pas la syntaxe et la sémantique appropriées de tout langage de programmation, les erreurs de temps de compilation sont générées par le compilateur. Ils ne laisseront pas votre programme exécuter une seule ligne jusqu'à ce que vous supprimiez toutes les erreurs de syntaxe ou jusqu'à ce que vous déboguez les erreurs de temps de compilation.
Exemple: il manque un point-virgule en C ou une faute int
de frappe comme Int
.
Erreurs d'exécution: les erreurs d' exécution sont les erreurs générées lorsque le programme est en cours d'exécution. Ces types d'erreurs provoquent un comportement inattendu de votre programme ou peuvent même tuer votre programme. Ils sont souvent appelés exceptions.
Exemple: supposons que vous lisez un fichier qui n'existe pas, cela entraînera une erreur d'exécution.
En savoir plus sur toutes les erreurs de programmation ici
En complément des autres réponses, voici comment je l'expliquerais à un profane:
Votre code source est comme le plan d'un navire. Il définit la manière dont le navire doit être construit.
Si vous remettez votre plan au chantier naval et qu'ils trouvent un défaut lors de la construction du navire, ils arrêteront de le construire et vous le signaleront immédiatement, avant que le navire n'ait jamais quitté la cale sèche ou touché l'eau. Il s'agit d'une erreur au moment de la compilation. Le navire n'a jamais flotté ni utilisé ses moteurs. L'erreur a été trouvée car elle empêchait même la construction du navire.
Lorsque votre code est compilé, c'est comme si le vaisseau était terminé. Construit et prêt à partir. Lorsque vous exécutez votre code, c'est comme lancer le navire en voyage. Les passagers sont montés à bord, les moteurs tournent et la coque est sur l'eau, c'est donc le temps d'exécution. Si votre navire a un défaut fatal qui le fait couler lors de son premier voyage (ou peut-être un voyage après pour des maux de tête supplémentaires), il a alors subi une erreur d'exécution.
Par exemple: dans un langage fortement typé, un type peut être vérifié au moment de la compilation ou au moment de l'exécution. Au moment de la compilation, cela signifie que le compilateur se plaint si les types ne sont pas compatibles. Au moment de l'exécution signifie que vous pouvez très bien compiler votre programme mais au moment de l'exécution, il lève une exception.
temps de compilation: le développeur écrit le programme au format .java et le convertit en Bytecode qui est un fichier de classe, pendant cette compilation, toute erreur qui se produit peut être définie comme une erreur de temps de compilation.
Exécution: le fichier .class généré est utilisé par l'application pour ses fonctionnalités supplémentaires et la logique s'avère incorrecte et génère une erreur qui est une erreur d'exécution
Voici une citation de Daniel Liang, auteur de «Introduction à la programmation JAVA», sur le sujet de la compilation:
"Un programme écrit dans un langage de haut niveau est appelé programme source ou code source. Puisqu'un ordinateur ne peut pas exécuter un programme source, un programme source doit être traduit en code machine pour exécution . La traduction peut être effectuée à l'aide d'un autre outil de programmation appelé un interprète ou un compilateur . " (Daniel Liang, "Introduction à la programmation JAVA" , p8).
...Il continue...
"Un compilateur traduit l'intégralité du code source en un fichier de code machine , puis le fichier de code machine est exécuté"
Lorsque nous introduisons du code de haut niveau / lisible par l'homme, cela est tout d'abord inutile! Il doit être traduit en une séquence d '«événements électroniques» dans votre minuscule petit processeur! La première étape vers cela est la compilation.
Autrement dit: une erreur de compilation se produit pendant cette phase, tandis qu'une erreur d'exécution se produit plus tard.
N'oubliez pas: ce n'est pas parce qu'un programme est compilé sans erreur qu'il s'exécutera sans erreur.
Une erreur d'exécution se produira dans la partie prête, en cours d'exécution ou en attente d'un cycle de vie de programme tandis qu'une erreur de compilation se produira avant la «nouvelle» étape du cycle de vie.
Exemple d'erreur de compilation:
Une erreur de syntaxe - comment votre code peut-il être compilé en instructions au niveau de la machine si elles sont ambiguës ?? Votre code doit être conforme à 100% aux règles syntaxiques du langage, sinon il ne peut pas être compilé en code machine fonctionnel .
Exemple d'erreur d'exécution:
Manque de mémoire - Un appel à une fonction récursive par exemple peut entraîner un débordement de pile compte tenu d'une variable d'un degré particulier! Comment cela peut-il être anticipé par le compilateur!? ça ne peut pas.
Et c'est la différence entre une erreur de compilation et une erreur d'exécution
Temps de compilation:
Les choses qui sont faites au moment de la compilation n'entraînent (presque) aucun coût lorsque le programme résultant est exécuté, mais peuvent entraîner un coût élevé lorsque vous générez le programme. Durée:
Plus ou moins exactement le contraire. Peu de coûts lorsque vous créez, plus de coûts lorsque le programme est exécuté.
Depuis l'autre côté; Si quelque chose est fait au moment de la compilation, il s'exécute uniquement sur votre machine et si quelque chose est en cours d'exécution, il s'exécute sur la machine de vos utilisateurs.
Temps de compilation: le temps nécessaire pour convertir le code source en code machine afin qu'il devienne un exécutable est appelé temps de compilation.
Exécution: lorsqu'une application est en cours d'exécution, elle est appelée exécution.
Les erreurs de compilation sont les erreurs de syntaxe, les erreurs de référence de fichier manquantes. Les erreurs d'exécution se produisent après que le code source a été compilé dans un programme exécutable et pendant l'exécution du programme. Les exemples sont des plantages de programmes, un comportement de programme inattendu ou des fonctionnalités qui ne fonctionnent pas.
Imaginez que vous êtes un patron et que vous avez un assistant et une femme de chambre, et que vous leur donnez une liste de tâches à faire, l'assistant (temps de compilation) saisira cette liste et fera une vérification pour voir si les tâches sont compréhensibles et que vous n'a pas écrit dans une langue ou une syntaxe gênante, il comprend donc que vous voulez affecter quelqu'un à un travail, donc il vous l'assigne et il comprend que vous voulez du café, donc son rôle est terminé et la femme de chambre (à l'exécution) commence à exécuter ces tâches alors elle va vous faire du café mais soudain elle ne trouve pas de café à faire donc elle arrête de le faire ou elle agit différemment et vous fait du thé (quand le programme agit différemment parce qu'il a trouvé une erreur ).
Voici une extension de la réponse à la question "différence entre l'exécution et la compilation?" - Différences de frais généraux associés à l'exécution et à la compilation?
Les performances d'exécution du produit contribuent à sa qualité en fournissant des résultats plus rapidement. Les performances de compilation du produit contribuent à sa rapidité en raccourcissant le cycle d'édition-compilation-débogage. Cependant, les performances au moment de l'exécution et les performances au moment de la compilation sont des facteurs secondaires pour obtenir une qualité en temps opportun. Par conséquent, il ne faut envisager des améliorations des performances au moment de l'exécution et de la compilation que lorsqu'elles sont justifiées par des améliorations de la qualité et de la rapidité globales des produits.
Une excellente source de lecture supplémentaire ici :
J'ai toujours pensé à cela par rapport aux frais généraux de traitement du programme et à la façon dont il affecte la performance comme indiqué précédemment. Un exemple simple serait de définir la mémoire absolue requise pour mon objet dans le code ou non.
Un booléen défini prend x mémoire, il se trouve alors dans le programme compilé et ne peut pas être modifié. Lorsque le programme s'exécute, il sait exactement combien de mémoire allouer à x.
D'un autre côté, si je ne définis qu'un type d'objet générique (c'est-à-dire une sorte d'espace réservé non défini ou peut-être un pointeur vers un objet géant), la mémoire réelle requise pour mon objet n'est pas connue jusqu'à ce que le programme soit exécuté et que je lui assigne quelque chose. , il doit donc être évalué et l'allocation de mémoire, etc. sera alors traitée dynamiquement au moment de l'exécution (plus de temps d'exécution).
La façon dont il est géré dynamiquement dépendrait alors de la langue, du compilateur, du système d'exploitation, de votre code, etc.
Sur cette note cependant, cela dépend vraiment du contexte dans lequel vous utilisez le temps d'exécution vs le temps de compilation.
nous pouvons les classer sous deux grands groupes, la liaison statique et la liaison dynamique. Il est basé sur le moment où la liaison est effectuée avec les valeurs correspondantes. Si les références sont résolues au moment de la compilation, il s'agit d'une liaison statique et si les références sont résolues au moment de l'exécution, il s'agit d'une liaison dynamique. La liaison statique et la liaison dynamique sont également appelées liaison précoce et liaison tardive. Parfois, ils sont également appelés polymorphisme statique et polymorphisme dynamique.
Joseph Kulandai.
La principale différence entre le temps d'exécution et le temps de compilation est:
int a = 1
int b = a/0;
ici, la première ligne n'a pas de point-virgule à la fin ---> erreur de compilation après l'exécution du programme lors de l'exécution de l'opération b, le résultat est infini ---> erreur d'exécution.
voici une réponse très simple:
Le temps d'exécution et le temps de compilation sont des termes de programmation qui font référence à différentes étapes du développement de logiciels. Afin de créer un programme, un développeur écrit d'abord le code source, qui définit le fonctionnement du programme. Les petits programmes peuvent ne contenir que quelques centaines de lignes de code source, tandis que les grands programmes peuvent contenir des centaines de milliers de lignes de code source. Le code source doit être compilé en code machine afin de devenir un programme exécutable. Ce processus de compilation est appelé temps de compilation (pensez à un compilateur comme un traducteur)
Un programme compilé peut être ouvert et exécuté par un utilisateur. Lorsqu'une application est en cours d'exécution, elle est appelée runtime.
Les termes "runtime" et "compile time" sont souvent utilisés par les programmeurs pour désigner différents types d'erreurs. Une erreur de temps de compilation est un problème tel qu'une erreur de syntaxe ou une référence de fichier manquante qui empêche le programme de réussir la compilation. Le compilateur génère des erreurs de compilation et indique généralement quelle ligne du code source est à l'origine du problème.
Si le code source d'un programme a déjà été compilé dans un programme exécutable, il peut toujours y avoir des bogues qui se produisent pendant l'exécution du programme. Les exemples incluent des fonctionnalités qui ne fonctionnent pas, un comportement de programme inattendu ou des plantages de programme. Ces types de problèmes sont appelés erreurs d'exécution car ils se produisent lors de l'exécution.
À mon humble avis, vous devez lire de nombreux liens, ressources pour vous faire une idée de la différence entre le temps d'exécution et le temps de compilation, car c'est un sujet très complexe. J'ai une liste ci-dessous de certaines de ces images / liens que je recommande.
Outre ce qui est dit ci-dessus, je veux ajouter que parfois une image vaut 1000 mots:
CLR_diag compile time puis runtime2
from Wiki
https://en.wikipedia.org/wiki/Run_time https://en.wikipedia.org/wiki/Run_time_(program_lifecycle_phase)
Le temps d'exécution, le temps d'exécution ou le temps d'exécution peuvent faire référence à:
L'informatique
Durée d' exécution (phase du cycle de vie du programme) , la période pendant laquelle un programme informatique s'exécute
Bibliothèque d'exécution , une bibliothèque de programmes conçue pour implémenter des fonctions intégrées dans un langage de programmation
Système d'exécution , logiciel conçu pour prendre en charge l'exécution de programmes informatiques
Exécution du logiciel, le processus d'exécution des instructions une par une pendant la phase d'exécution
Liste des compilateurs https://en.wikipedia.org/wiki/List_of_compilers
;
3.2 la différence entre ces 3 choses: compilation vs build vs runtime
https://www.quora.com/What-is-the-difference-between-build-run-and-compile Fernando Padoan, un développeur qui est juste un peu curieux pour la conception de langage Répondu le 23 février Je recule par rapport à d'autres réponses:
courir, c'est faire exécuter un exécutable binaire (ou un script, pour les langages interprétés), enfin… comme un nouveau processus sur l'ordinateur; la compilation est le processus d'analyse d'un programme écrit dans un langage de haut niveau (supérieur par rapport au code machine), de vérification de sa syntaxe, de sa sémantique, de la liaison de bibliothèques, peut-être d'une optimisation, puis de création d'un programme exécutable binaire en sortie. Cet exécutable peut prendre la forme d'un code machine ou d'une sorte de code octet, c'est-à-dire des instructions ciblant une sorte de machine virtuelle; la construction implique généralement la vérification et la fourniture de dépendances, l'inspection du code, la compilation du code en binaire, l'exécution de tests automatisés et le conditionnement du ou des binaires résultants et d'autres actifs (images, fichiers de configuration, bibliothèques, etc.) dans un format spécifique de fichier déployable. Notez que la plupart des processus sont facultatifs et certains dépendent de la plateforme ciblée pour laquelle vous construisez. Par exemple, le conditionnement d'une application Java pour Tomcat produira un fichier .war. La construction d'un exécutable Win32 à partir de code C ++ pourrait simplement générer le programme .exe, ou pourrait également l'intégrer dans un programme d'installation .msi.
Regardez cet exemple:
public class Test {
public static void main(String[] args) {
int[] x=new int[-5];//compile time no error
System.out.println(x.length);
}}
Le code ci-dessus est compilé avec succès, il n'y a pas d'erreur de syntaxe, il est parfaitement valide. Mais au moment de l'exécution, il génère l'erreur suivante.
Exception in thread "main" java.lang.NegativeArraySizeException
at Test.main(Test.java:5)
Comme lors de la compilation, certains cas ont été vérifiés, après ce temps d'exécution, certains cas ont été vérifiés une fois que le programme satisfait à toutes les conditions, vous obtiendrez une sortie. Sinon, vous obtiendrez une erreur de compilation ou d'exécution.
classe publique RuntimeVsCompileTime {
public static void main(String[] args) {
//test(new D()); COMPILETIME ERROR
/**
* Compiler knows that B is not an instance of A
*/
test(new B());
}
/**
* compiler has no hint whether the actual type is A, B or C
* C c = (C)a; will be checked during runtime
* @param a
*/
public static void test(A a) {
C c = (C)a;//RUNTIME ERROR
}
}
class A{
}
class B extends A{
}
class C extends A{
}
class D{
}
Ce n'est pas une bonne question pour SO (ce n'est pas une question de programmation spécifique), mais ce n'est pas une mauvaise question en général.
Si vous pensez que c'est trivial: qu'en est-il du temps de lecture par rapport au temps de compilation, et quand est-ce une distinction utile à faire? Qu'en est-il des langues dans lesquelles le compilateur est disponible au moment de l'exécution? Guy Steele (pas de mannequin, il) a écrit 7 pages en CLTL2 sur EVAL-WHEN, que les programmeurs CL peuvent utiliser pour contrôler cela. 2 phrases suffisent à peine pour une définition qui elle-même est loin d'être expliquée .
En général, c'est un problème difficile que les concepteurs de langage semblent essayer d'éviter. Ils disent souvent simplement "voici un compilateur, il fait des choses au moment de la compilation; tout ce qui est après l'exécution, amusez-vous". C est conçu pour être simple à implémenter, pas l'environnement le plus flexible pour le calcul. Lorsque vous n'avez pas le compilateur disponible au moment de l'exécution, ou la possibilité de contrôler facilement quand une expression est évaluée, vous avez tendance à vous retrouver avec des hacks dans le langage pour simuler les utilisations courantes des macros, ou les utilisateurs proposent des modèles de conception pour simuler ayant des constructions plus puissantes. Un langage simple à implémenter peut certainement être un objectif valable, mais cela ne signifie pas qu'il s'agit de la conception ultime de tout langage de programmation. (Je n'utilise pas beaucoup EVAL-WHEN, mais je ne peux pas imaginer la vie sans.)
Et l'espace de problèmes autour de la compilation et de l'exécution est énorme et encore largement inexploré. Cela ne veut pas dire que SO est le bon endroit pour discuter, mais j'encourage les gens à explorer davantage ce territoire, en particulier ceux qui n'ont aucune idée préconçue de ce qu'il devrait être. La question n'est ni simple ni idiote, et nous pourrions au moins orienter l'inquisiteur dans la bonne direction.
Malheureusement, je ne connais pas de bonnes références à ce sujet. CLTL2 en parle un peu, mais ce n'est pas génial pour en savoir plus.