Bonjour et bienvenue.
Dans cette vidéo, je vais vous montrer comment construire et exécuter le programme de la vidéo précédente.
Si vous vous souvenez, nous avions un petit programme qui demandait à l'utilisateur d'entrer son
numéro préféré et qui l'imprimait.
D'après les vidéos précédentes, vous devriez comprendre qu'il y a de nombreuses étapes pour créer un programme que vous pouvez
exécuter.
Il faut compiler, lier et créer le binaire.
Ainsi, jusqu'à ce stade, nous avons pu compiler avec succès.
Nous ne voyons aucune erreur.
Nous devons maintenant prendre toutes les dépendances externes pour ce programme, écrire le fichier d'en-tête standard
i o et toutes les autres bibliothèques fournies par le langage de programmation C.
Vous prenez tout cela, qui peut être plusieurs fichiers O, et vous prenez tout ce code externe pour créer un seul
exécutable.
C'est vrai ?
Voici donc notre code source.
Vous verrez que le code source est en quelque sorte regroupé.
Vous pouvez en fait rendre ce code un peu plus lisible en ajoutant de nouvelles lignes, quelque chose comme ceci.
Cela rend le texte un peu plus lisible.
Comme je l'ai dit, nous l'avons déjà compilé.
Pour vous rafraîchir la mémoire, vous pouvez compiler un fichier source de différentes manières.
Vous pouvez faire un clic droit sur le fichier source et dire "compiler", ou vous pouvez sélectionner ce fichier
source, aller à "build" et dire "compiler le fichier actuel".
Si nous sélectionnons notre projet, vous verrez de nombreuses options liées à la construction.
Vous voyez construire, reconstruire, nettoyer, arrêter, construire.
Parlons d'abord de la propreté.
La fonction Nettoyer va permettre d'effacer tous les anciens fichiers que vous possédez.
Rappelez-vous donc au préalable, dans les vidéos précédentes, qu'un programme C, lorsqu'il est compilé, compile chaque fichier source et qu'un
programme peut être constitué de nombreux fichiers sources.
Main dot C D'autres fichiers également ?
Certains programmes contiennent des milliers et des milliers de fichiers source en C.
Une fois que vous avez compilé tous ces fichiers C, cela crée tous les anciens fichiers, puis vous prenez ces anciens
fichiers et vous les liez ensemble pour créer un seul exécutable.
Maintenant, lorsque vous sélectionnez le projet, que vous définissez le soi du projet et que vous dites "nettoyer", ce que
vous faites, c'est que vous supprimez tous ces vieux fichiers, vous supprimez tous les artefacts supplémentaires, vous supprimez
l'exécutable du programme et vous repartez de zéro.
Vous obtenez essentiellement un espace de travail propre que vous pouvez ensuite recompiler, reconstruire, relier et recréer un
programme lui-même.
Typiquement, vous voulez utiliser clean si vous rencontrez des erreurs et peut-être que vous voulez juste recompiler
chaque fichier source parce que typiquement, quand vous exécutez un compilateur C, si le code tel qu'il est ne change pas et que vous essayez de compiler ce
code, il ne le recompile généralement pas.
Ainsi, si vous rencontrez des problèmes, si vous avez beaucoup de fichiers sources, si vous voyez des erreurs
qui n'ont pas de sens.
Il peut être judicieux de commencer par un état de propreté, d'aller au nettoyage, de tout nettoyer.
Vous dites "propre" et il vous montrera exactement ce qu'il en est.
Il s'agit en fait de supprimer tout ce qui se trouve dans le dossier de construction et de débogage.
Encore une fois, tous ces points os l'exécutable, vous partez de zéro.
C'est un bon moyen de résoudre les dépendances ou les problèmes sans avoir à recompiler tout
le projet pour repartir de zéro.
Ainsi, après avoir exécuté clean, nous n'avons rien compilé ou construit et nous pouvons passer en revue et compiler des fichiers
individuels en disant compile et en cliquant sur chaque fichier.
Si vous avez de nombreux fichiers sources, ce n'est pas vraiment une bonne façon d'obtenir l'exécutable final.
Typiquement, ce qui se passe, c'est que vous voulez vous assurer que vous avez votre projet d'application
et que vous dites simplement "build", ce qui va parcourir tout le code source de votre projet et construire tous les fichiers.
Ainsi, lorsque vous appuyez sur "build", vous verrez qu'il va chercher tous les codes sources et les reconstruire.
De même, si vous cliquez avec le bouton droit de la souris et que vous dites "reconstruire", cela ne reconstruira pas tous les fichiers
ou seulement les fichiers qui ont été modifiés.
Vous pouvez donc dire build, ce qui rend les choses un peu plus faciles que de compiler chaque fichier source.
La compilation va à nouveau compiler tous les fichiers sources, mais aussi les lier pour que vous puissiez voir cela dans la
sortie, n'est-ce pas ?
Si vous allez dans la fenêtre de sortie de la compilation, vous pouvez voir que nous émettons d'abord une commande GCC dash
C, qui est le drapeau pour compiler sur main dot C. Nous passons ensuite des paramètres pour l'optimisation de l'architecture 64, un peu
de débogage standard C, 99 avertissements pour tous les avertissements.
Ensuite, nous faisons le tiret o pour faire le lien avec le Main. cpp.
Nous allons également inclure des répertoires d'inclusion.
Puis, à l'étape suivante, nous émettons le tiret zéro pour établir le lien avec chaque dépendance externe.
Dans ce cas, nous n'en avons pas vraiment beaucoup, nous avons simplement un lien, nous avons un lien statique
avec le tiret L et nous construisons essentiellement ce texte de liste d'objets.
Ce qui est important ici, c'est qu'il crée un exécutable nommé notre premier programme.
Voir.
Et donc le bâtiment fait les deux étapes d'un programme C, n'est-ce pas ?
Il le compile, le lie et crée l'exécutable.
Cela facilite donc les choses en construisant plutôt qu'en compilant tout d'abord.
Il se peut que vous souhaitiez compiler des fichiers individuels pour voir ce qui se passe, pour vous assurer que votre code source
est correct et que vous n'êtes pas prêt pour l'édition de liens.
Vous pouvez avoir cinq dossiers ici.
Vous sélectionnez chacun d'entre eux pour dire, ok, je viens d'écrire un peu de code, compilons-le,
assurons-nous que tout va bien, puis j'irai chercher le fichier suivant, je le compilerai et enfin vous construirez tout.
Maintenant que nous avons créé un programme exécutable, nous pouvons exécuter notre programme.
Vous devez donc vous assurer que votre programme, votre projet, est le projet actif et qu'il est mis en évidence, puis vous pouvez
aller jusqu'à la construction et vous pouvez simplement dire "exécuter".
Maintenant, lorsque vous sélectionnez Exécuter, vous obtiendrez probablement cette fenêtre contextuelle qui vous dira : Voulez-vous reconstruire et
exécuter ?
Maintenant que vous avez déjà construit, vous n'avez plus besoin de le faire.
Vous pouvez simplement dire "exécuter".
Vous pouvez cocher la case pour vous assurer que cela ne se produise pas systématiquement.
Et lorsque vous fuyez, il n'y a pas toujours de reconstruction.
C'est à vous de décider.
Il faut un peu de temps de traitement CPU pour tout reconstruire, mais cela ne vous préoccupe probablement pas.
Vous pouvez donc toujours dire "construire et exécuter" et ne pas avoir de "pop up" ou vous pouvez toujours simplement exécuter.
Maintenant, si nous sélectionnons exécuter, il va prendre cet exécutable et l'exécuter.
Ce que vous remarquerez, c'est qu'il vous demande d'entrer votre numéro préféré, l'utilisateur.
Vous pouvez donc entrer le chiffre 45, appuyer sur la touche Entrée du clavier et l'écran affichera
le chiffre 45 que vous avez entré.
Là encore, un programme très simple demande une entrée, affiche une sortie, puis vous pouvez appuyer sur n'importe quelle touche pour continuer
et fermer cette fenêtre.
Maintenant, si nous retournons à notre espace de travail, notre fenêtre d'espace de travail, notre panneau d'espace de travail, quel que soit le nom
que vous lui donnez, vous remarquez que nous avons trois projets, n'est-ce pas ?
Notre premier programme est mis en avant.
C'est le projet actif.
Les autres projets contiennent toujours leurs fichiers sources, n'est-ce pas ?
Main dot C, Right.
Quant à nos autres projets, ils sont en grande partie modélisés.
Hello, World Code.
Mais ce que vous ne voyez pas, c'est que vous ne voyez aucun fichier objet, aucun fichier point
zéro, aucun fichier exécutable, rien de tout cela.
Vous pouvez maintenant les afficher en cliquant sur l'onglet Explorateur et vous pouvez spécifier un dossier à ouvrir.
Il s'agit généralement du dossier racine dans lequel vous créez tous vos espaces de travail.
Je les place donc généralement, je pense que je les place dans des documents à l'intérieur de documents.
J'ai mes espaces de travail.
Vous verrez qu'il y a beaucoup de choses à l'intérieur.
En règle générale, il est préférable de le placer au niveau local, mais vous verrez que vous avez un espace de travail 1 et un espace de travail
2, et que cet espace de travail contient le fichier point code light.
En fait, il est probablement préférable d'ouvrir les fichiers exacts de l'espace de travail, n'est-ce pas ?
Parce que c'est seulement cela qui nous intéresse.
L'espace de travail 2 est celui qui nous intéresse.
Nous allons donc sélectionner le dossier, l'espace de travail deux, puis nous allons fermer nos documents existants, ce qui nous permettra
d'aller de l'avant et de dire "fermer".
Nous avons maintenant l'espace de travail 2 et nous pouvons voir tous nos exécutables
pour tous nos projets et tous nos fichiers.
Vous remarquerez donc qu'il y a un dossier sur les feux de code.
Ce répertoire code light contient simplement certaines préférences pour l'espace de travail et ainsi de suite.
Nous avons notre dossier de construction et de débogage.
Il contient notre répertoire binaire qui contient notre exécutable et vous remarquerez que nous avons également un répertoire R first program
qui se trouve dans build debug parce que cet espace de travail, ce projet a été construit et vous verrez qu'il contient nos fichiers
objets et toutes les autres dépendances qui sont construites dans cette liste
d'objets.
Nous avons en fait notre premier projet de programme, n'est-ce pas ?
Et cela concerne notre fichier source et tous les autres fichiers make et ainsi de suite.
Il en va de même pour les autres projets.
Et tout en bas, vous voyez les commandes de compilation, point JSON.
Elle est généralement utilisée pour compléter le code.
Vous voyez un fichier make et ensuite un fichier workspace.
Mais l'onglet Explore nous permet de voir l'ensemble de notre espace de travail, tous nos projets, tout ce qui a été construit, tous les fichiers
de configuration du projet et tous les fichiers source du projet, ainsi que toutes les dépendances sur les fichiers de complétion
de code et ainsi de suite pour l'espace de travail lui-même.
Nous avons donc parlé de propreté, n'est-ce pas ?
La méthode de nettoyage permet de tout supprimer, tous les fichiers objets de l'exécutable.
Si nous retournons à la vue de l'espace de travail et que nous mettons en surbrillance notre premier projet de programme, en cliquant avec le bouton
droit de la souris et en disant "nettoyer", cela va supprimer tous ces projets.
Ainsi, si vous retournez à l'onglet Explorer et que vous allez au build debug, vous verrez tout ce qu'il y a dedans
parce qu'il n'a pas été rafraîchi.
Vous pouvez donc rafraîchir cette vue.
Je vais donc faire un clic droit sur notre espace de travail et je vais dire "rafraîchir le dossier de construction et de débogage".
Il est généralement supprimé, mais il n'y a rien dedans, n'est-ce pas ?
Il se peut que vous ayez à nouveau une poubelle.
En général, cela se nettoie.
Cela dépend des autorisations, mais vous n'avez pas d'anciens fichiers.
Vous n'avez pas votre exécutable après avoir fait un nettoyage.
Encore une fois, si nous retournons à l'espace de travail, vous pouvez voir ce petit menu déroulant qui vous indique ce qu'il faut construire,
si vous construisez pour le débogage ou si vous construisez pour la version.
Lorsque vous construisez pour le débogage, les informations de débogage sont incluses dans l'exécutable du programme lui-même.
Cela se produit généralement lorsque vous développez votre code.
Vous souhaitez obtenir des informations sur le débogage et, le cas échéant, lancer le débogueur, etc.
Il n'est pas toujours bon de le faire lorsque vous diffusez un programme sur le terrain ou auprès d'un client en mode
production, afin de pouvoir modifier la version lorsque vous construisez et que vous souhaitez distribuer ce programme
quelque part.
Ainsi, lorsque vous le construisez, vous remarquerez que si vous allez dans l'onglet "Explorer", vous verrez qu'il faut à nouveau
rafraîchir la page.
Vous verrez un dossier "build release" qui ne contiendra pas les informations de débogage, vous n'aurez donc pas à vous
en préoccuper.
En fait, si vous disposez d'informations de débogage, vous pouvez générer un fichier de base et des pirates
peuvent obtenir des informations sur votre code source.
Ainsi, vous ne construisez que le mode débogage lorsque vous développez et vous passez au mode release
lorsque vous lancez votre programme auprès d'un client.
Encore une fois, cela dépend si vous travaillez quelque part ou si vous travaillez pour un employé,
si vous livrez un code quelque part.
En général, vous ne modifiez rien dans l'onglet Explorer.
Il vous donne simplement un aperçu de ce qui a été construit, de vos exécutables, etc.
Là encore, j'ai indiqué que vous voyiez des fichiers d'aide.
Vous pouvez examiner certains de ces éléments.
Certains de ces éléments seront générés automatiquement.
Vous pouvez voir un fichier make ici.
Il s'agit en fait d'un fichier make qui peut être généré en fonction des paramètres de votre projet.
Il s'agit d'un fichier make pour l'ensemble de l'espace de travail.
Vous pouvez consulter des programmes spécifiques et voir certains des fichiers make qui sont générés à nouveau, mais en général, vous ne voulez
pas vous mêler de ces choses.
Il s'agit encore une fois d'un fichier make à compiler.
Parfois, lorsque vous avez des erreurs, vous pouvez regarder le fichier make pour voir exactement ce qui se passe.
Peut-être que quelque chose n'a pas été généré correctement.
Le code comme parfois a quelques bogues selon le système de marque que vous utilisez.
Là encore, nous utilisons généralement le système de création de fichiers UNIX si vous êtes sous Windows, et si vous êtes sous Linux ou
Mac OS, vous utilisez simplement le système par défaut.
C'est donc tout ce qu'il y a à faire, n'est-ce pas ?
Vous pouvez fermer ces fichiers, mais vous pouvez voir ce qui se passe dans l'explorateur et dans l'espace de travail.
Dans la vue de l'espace de travail, si vous sélectionnez un projet, vous pouvez également dire stop, build.
Ainsi, la compilation et la construction de votre exécutable peuvent parfois prendre beaucoup de temps.
Si vous avez des milliers de fichiers, vous pouvez construire pendant 30 minutes.
Donc, stop, build vous permet d'arrêter de construire quoi que ce soit, vous savez, de compiler et de lier quoi que ce soit, n'importe
lequel des projets.
Encore une fois, c'est utile lorsque le processus de compilation est long, mais ce n'est généralement pas le cas dans le code que
nous allons écrire pour notre classe.
L'autre chose qui pourrait être intéressante, c'est que si vous mettez en surbrillance la vue de l'espace de travail, vous pouvez construire tous
les projets en une seule fois.
Vous pouvez dire build workspace ou clean workspace et supprimer toutes les dépendances pour tous les projets.
Mais si vous dites construire l'espace de travail, cela construira tous les projets, qu'ils soient actifs ou non, et c'est ce
que vous voyez dans la fenêtre de sortie.
C'est vrai.
Nous construisons le projet trois, nous construisons le projet deux et nous construisons notre premier programme.
Encore une fois, voici un bref aperçu de la façon dont vous pouvez construire et exécuter votre code à partir du projet actif, de certains
paramètres et de la façon dont vous pouvez voir l'onglet Explorateur.
Nous vous remercions.