Hallo en welkom.
In deze video laat ik je zien hoe je het programma uit de vorige video bouwt en uitvoert.
Dus als je je herinnert, hadden we een klein programma dat de gebruiker vroeg om zijn favoriete nummer in te voeren
en dan dat favoriete nummer af te drukken.
Dus uit eerdere video's zou je moeten begrijpen dat er veel stappen zijn om een programma te maken dat je kunt uitvoeren.
Je moet compileren, je moet linken, en dan moet je die binary maken.
En dus konden we tot nu toe succesvol compileren.
We zien geen fouten.
Nu moeten we eigenlijk alle externe afhankelijkheden voor dit programma nemen, standaard i o header-bestand
schrijven en alle andere bibliotheken die de programmeertaal C biedt.
U neemt dat alles, wat vele O-bestanden kunnen zijn, en neemt al die externe code om één enkel uitvoerbaar bestand
te maken.
Toch?
Dus hier hebben we onze broncode.
Je zult zien dat de broncode bij elkaar staat.
U kunt deze code een beetje leesbaarder maken door enkele nieuwe regels toe te voegen, zoiets als
dit.
Het maakt het alleen wat leesbaarder.
Zoals ik al zei, we hebben het al samengesteld.
Om uw geheugen op te frissen: u kunt een bronbestand op veel verschillende manieren compileren.
U kunt rechts klikken op het bronbestand en zeggen compileren, of u kunt het bronbestand
selecteren, naar build gaan en zeggen compileren.
Als we ons project selecteren, zie je veel verschillende opties met betrekking tot bouwen.
Je ziet bouwen, herbouwen, schoonmaken, stoppen, bouwen.
Laten we het eerst over schoon hebben.
Schoon zal in principe alle oude bestanden wissen.
Onthoud dus van tevoren in eerdere video's dat een C-programma, wanneer het wordt gecompileerd, elk bronbestand compileert,
en een programma kan uit vele bronbestanden bestaan.
Main dot C Nog andere bestanden?
Er zijn programma's die duizenden en duizenden C-bronbestanden bevatten.
Zodra je al die C-bestanden compileert, creëert het alle oude bestanden en dan neem je die oude bestanden
en koppel je ze aan elkaar om één uitvoerbaar bestand te maken.
Als je nu het project selecteert, het project zelf instelt en schoon zegt, dan verwijder
je in feite al die oude bestanden, je verwijdert alle extra artefacten, je verwijdert het
programma en je begint opnieuw.
Je krijgt in wezen een schone werkruimte die je vervolgens kunt hercompileren, herbouwen, herlinken en zelf een programma
kunt maken.
Normaal gesproken wil je clean gebruiken als je fouten tegenkomt en misschien wil je gewoon elk bronbestand
opnieuw compileren, want als je een C compiler draait, als de code niet verandert en je probeert die code te compileren, wordt hij meestal
niet opnieuw gecompileerd.
En dus als je tegen problemen aanloopt, je hebt veel bronbestanden, je ziet fouten die
nergens op slaan.
Het kan goed zijn om vanuit een schone staat te beginnen, ga naar schoon, maak alles schoon.
Je zegt schoon en het zal je precies dat laten zien.
Het is eigenlijk alles verwijderen uit je build debug map.
Nogmaals, al die puntjes os de executable begin je vanaf nul.
Het is een mooie manier om elke soort afhankelijkheid of elk soort probleem op te lossen zonder het hele project opnieuw
te compileren en vanaf nul te beginnen.
Dus na het uitvoeren van clean, hebben we nog niets gecompileerd of gebouwd en kunnen we individuele bestanden compileren
door compileren te zeggen en op elk bestand te klikken.
Als je veel bronbestanden hebt, is dat niet echt een goede manier om tot het uiteindelijke uitvoerbare bestand te komen.
Gewoonlijk wil je ervoor zorgen dat je je app project hebt en dan
zeg je gewoon bouwen en dat gaat door alle broncode in je project en bouwt alle bestanden.
Dus als je op bouwen drukt, zie je dat het alle broncodes pakt en opnieuw bouwt.
En hetzelfde als wanneer je met de rechtermuisknop klikt en zegt herbouwen, zal dit niet alle bestanden herbouwen
of alleen de bestanden die veranderd zijn.
En dus kun je zeggen bouwen, wat het wat makkelijker maakt dan elk bronbestand te compileren.
De build zal eigenlijk weer alle bronbestanden compileren, maar ook koppelen, zodat je dat in de uitvoer
kunt zien, toch?
Als u naar het uitvoervenster van de build gaat, kunt u zien dat we eerst een GCC commando streepje C geven, wat
de vlag is voor het compileren op main dot C, Vervolgens geven we parameters door voor 64 architectuur optimalisatie, wat
debugging standaard C, 99 waarschuwingen voor alle waarschuwingen.
En dan doen we het streepje o om naar de Main te linken. cpp bestand.
We gaan in principe ook enkele include directories opnemen.
En dan in de volgende stap, juist, geven we het streepje nul om te linken naar elke externe afhankelijkheid.
In dit geval hebben we niet echt veel, we hebben in principe alleen maar linken, we linken statisch
met de Dash L en we bouwen in principe deze objectlijst tekst op.
Het belangrijkste hier is dat het een uitvoerbaar programma maakt met de naam van ons eerste programma.
Zie.
En zo doet bouwen beide stappen van een C-programma, toch?
Het compileert het en koppelt het en maakt het uitvoerbaar.
En dus maakt het de dingen makkelijker door te bouwen in plaats van alles eerst te compileren.
Nu wil je misschien individuele bestanden compileren, gewoon om te zien wat er aan de hand is, om er zeker van te zijn dat je
broncode correct is en dat je niet klaar bent om te koppelen.
Je mag hier vijf bestanden hebben.
Je selecteert elk bestand om te zeggen, oké, ik heb net wat code geschreven, laten we het
compileren, zorgen dat het allemaal goed gaat, en dan ga ik naar het volgende bestand, compileer dat en uiteindelijk
bouw je alles.
Nu we een echt uitvoerbaar programma hebben gemaakt, kunnen we ons programma uitvoeren.
En dus wilt u ervoor zorgen dat uw programma, uw project als het actieve project is gemarkeerd,
en dan kunt u naar build gaan en gewoon run zeggen.
Als u nu Run selecteert, krijgt u waarschijnlijk een pop-up die zegt: Wilt u opnieuw bouwen en uitvoeren?
Nu heb je al gebouwd, dus dat is niet echt nodig.
Je kunt gewoon zeggen uitvoeren.
U kunt het selectievakje inschakelen om ervoor te zorgen dat dit niet altijd gebeurt.
En als je vlucht, wordt het niet altijd weer opgebouwd.
Het is aan jou.
Het kost wat CPU-verwerkingstijd om alles opnieuw op te bouwen, maar daar maak je je waarschijnlijk geen zorgen over.
Dus je kunt altijd zeggen bouwen en uitvoeren en geen pop-up hebben of je kunt altijd gewoon uitvoeren.
Als we nu uitvoeren selecteren, wordt het uitvoerbare programma uitgevoerd.
En je zult merken dat het je vraagt om je favoriete nummer in te voeren, de gebruiker.
En dus kun je gewoon een nummer 45 invoeren, op de enter toets van het toetsenbord drukken en dan zal het gewoon
tonen dat je nummer 45 invoert.
Nogmaals, een heel eenvoudig programma vraagt om invoer, toont, voert uit, en dan kun je op een willekeurige toets drukken om verder te
gaan en dat venster te sluiten.
Als we nu teruggaan naar onze werkruimteweergave, ons werkruimtevenster, ons werkruimtevenster, hoe je het
ook wilt noemen, zie je dat we drie projecten hebben, toch?
Ons eerste programma wordt uitgelicht.
Dat is het actieve project.
De andere projecten hebben toch nog steeds hun bronbestanden?
Hoofdpunt C, rechts.
En onze andere projecten, die zijn vrij standaard.
Hallo, World Code.
Maar wat je niet ziet is dat je geen van de objectbestanden ziet, de dot zero bestanden, je
ziet het uitvoerbare bestand niet, niets van dat alles.
Nu kunt u die bekijken door op het tabblad Verkenner te klikken en u kunt een map opgeven om te openen.
En meestal moet dit de hoofdmap zijn van waar u al uw werkruimten maakt.
Dus ik zet ze meestal, ik denk dat ik ze in documenten binnen of juist binnen documenten zet.
Ik heb mijn werkplekken.
Je zult zien dat er veel in zit.
Dus normaal gesproken wil je dat lokaal zetten, maar je zult zien dat je Werkruimte één en Werkruimte twee hebt, en
je zult zien dat die werkruimte het dot code light bestand heeft.
Eigenlijk kun je waarschijnlijk beter de exacte werkruimtebestanden openen, toch?
Want dat is eigenlijk alleen wat ons interesseert.
Werkruimte twee is waar we in geïnteresseerd zijn.
Dus laten we zeggen selecteer map, werkruimte twee, en dan gaan we verder en sluiten onze bestaande documenten zodat we verder kunnen
gaan en gewoon kunnen zeggen sluiten.
Dus nu hebben we Werkruimte twee en kunnen we al onze uitvoerbare
bestanden en projecten zien.
En dus zie je dat er een code light folder in zit.
Die code light directory bevat alleen wat voorkeuren voor de werkruimte en zo.
We hebben onze build debug map.
Deze bevat onze binaire map met ons uitvoerbaar programma en u zult zien dat we ook een R first program directory hebben
en die zit in build debug omdat die werkruimte, dat project is gebouwd en u zult zien dat we daar onze objectbestanden
hebben en alle andere afhankelijkheden die zijn gebouwd deze objectlijst.
We hebben eigenlijk ons eerste programma project, toch?
En dat betreft ons bronbestand en eventuele andere make-bestanden enzovoort.
En je ziet hetzelfde voor de andere projecten.
En dan helemaal onderaan zie je compileer commando's, punt JSON.
Dit wordt meestal gebruikt voor code completion.
Je ziet een make bestand en dan zie je een workspace bestand.
Maar het tabblad Verkennen helpt ons onze hele werkruimte lay-out te zien, al onze projecten, alles wat is gebouwd,
alle projectinstellingen en alle projectbronbestanden, en ook eventuele afhankelijkheden van code completion
bestanden enzovoort voor de werkruimte zelf.
En dus spraken we over schoon, toch?
Hoe schoon kan eigenlijk alles verwijderen, alle object bestanden in de executable.
Dus als we teruggaan naar Workspace View en we markeren ons eerste programma project als we rechts klikken
en we zeggen clean, dan worden die allemaal verwijderd.
Dus als je nu teruggaat naar je Explorer tab en je gaat naar de build debug, dan zie je daar alles
omdat het niet ververst is.
Dus je kunt dit beeld verversen.
Dus ik ga rechts klikken op onze werkruimte en ik zeg ververs de build debug map.
Dus dat wordt meestal verwijderd, maar er zit niets in, toch?
Je hebt misschien weer een bak.
Meestal wordt dat opgeruimd.
Hangt van de rechten af, maar je hebt geen oude bestanden.
Je hebt je uitvoerbaar niet na een schoonmaakbeurt.
Nogmaals, als we teruggaan naar de werkruimte, zie je dit kleine dropdown menu dat je vertelt wat
je moet bouwen, of je bouwt voor debug of voor release.
Wanneer u bouwt voor debug, wordt debug-informatie opgenomen in het uitvoerbare programma zelf.
Dat gebeurt meestal als je je code ontwikkelt.
U wilt debug-informatie en voor het geval u de debugger en zo moet draaien.
Dat is niet altijd goed om te doen wanneer je een of ander programma vrijgeeft in het veld of aan een klant in productiemodus,
zodat je de vrijgave kunt veranderen in een release wanneer je aan het bouwen bent en dit programma ergens wilt distribueren.
En dus als je het bouwt, zul je merken dat als je naar de verkenningstab gaat, je opnieuw een verversing
ziet.
U zult een build release map zien en daarin ontbreekt in wezen de debug-informatie, zodat u zich geen zorgen
hoeft te maken.
Als je debug-informatie hebt, kun je een kernbestand genereren en kun je hackers hebben
die informatie over je broncode kunnen krijgen.
Dus je bouwt alleen debug voor de debug modus als je aan het ontwikkelen bent en je verandert het in build release
modus als je misschien je programma vrijgeeft aan een klant.
Nogmaals, het hangt ervan af of je ergens werkt, of je voor een werknemer werkt,
of je ergens code aflevert.
Meestal wijzigt u niet echt iets in de Explorer tab.
Het geeft je gewoon een overzicht van wat er gebouwd is en je uitvoerbare bestanden enzovoort.
Nogmaals, ik zei dat je wat hulpbestanden ziet.
Je kunt naar sommige van deze dingen kijken.
Sommige van deze dingen worden automatisch gegenereerd.
Je kunt hier een make-bestand zien.
En dit is eigenlijk een make-bestand dat gegenereerd kan worden, afhankelijk van uw projectinstellingen.
Dit is een make-bestand voor de hele werkruimte.
Je kunt naar specifieke programma's kijken en sommige van de make-bestanden die worden gegenereerd terugzien, maar meestal wil je niet
met dit soort dingen knoeien.
Dit levert gewoon weer een make bestand op om te compileren.
Soms kun je bij fouten in het make-bestand kijken wat er precies aan de hand is.
Misschien is er iets niet goed gegenereerd.
Code zoals deze heeft soms wat bugs afhankelijk van welk merk systeem je gebruikt.
Nogmaals, wij gebruiken meestal het UNIX-bestandssysteem voor Windows en voor Linux
of Mac OS de standaardinstellingen.
Dus dat is het eigenlijk, toch?
U kunt deze bestanden sluiten, maar u ziet wat er gebeurt in de Verkenner en de werkruimte.
Nu in de Werkruimte weergave, opnieuw, als je een project selecteert, kun je ook stoppen, bouwen zeggen.
Dus soms kan het compileren en bouwen van uw uitvoerbaar bestand lang duren.
Ik bedoel, als je duizenden bestanden hebt, kun je 30 minuten bouwen.
Dus stop, build laat je stoppen met bouwen, compileren en linken, elk
project.
Nogmaals, handig voor als je een lang compilatieproces hebt, maar dat zie je meestal niet in de code die we gaan
schrijven voor onze klasse.
Wat ook leuk zou kunnen zijn, is dat als je de werkruimteweergave markeert, je alle projecten in
één keer kunt bouwen.
U kunt zeggen build workspace of clean workspace en alle afhankelijkheden voor alle projecten verwijderen.
Maar als je zegt werkruimte bouwen, dan bouwt dat alle projecten, ongeacht of het actief is en dat is wat
je ziet in het uitvoervenster.
Juist.
We bouwen project drie, we bouwen project twee en we bouwen ons eerste programma.
En dus nogmaals, een kort overzicht van hoe je eigenlijk je code kunt bouwen en uitvoeren vanuit het actieve project, enkele
van de instellingen en hoe je je Explorer tabblad kunt zien.
Bedankt.