Hallo, en welkom terug.
In deze lezing wil ik graag om te praten over wat
er komt kijken bij het maken van een c-programma.
Er zijn dus vier fundamentele taken: bij het maken van een c-programma.
En wat deze taken zijn? omvatten bewerken, compileren, koppelen
en uitvoeren.
We hebben het gehad over de verschillende stappen die je zult gebruiken
als je een c-programma schrijft in termen van je gaat om de vereisten te begrijpen, ga
je je code ontwerpen, je bent je code gaat schrijven, dan
ga je hem testen en debuggen enzovoort en dan onderhouden.
Waar ik het hier over heb is wat je eigenlijk moet doen als je begint met
het schrijven van een programma. We hebben een beetje gepraat over bewerken, compileren maar
ook koppelen en uitvoeren zijn ook belangrijk.
En waar ik het over wil hebben hier zijn de details hiervan.
Dus deze taken worden tweede natuur voor je omdat je het
gaat doen elke keer dat u een c-programma schrijft.
Je gaat je . bewerken broncode, je
gaat compileren, je gaat linken, en dan ga je rennen.
Je gaat het doen dit heel, heel vaak.
Dus de bewerkingsprocessen, compileren, koppelen en uitvoeren zijn hetzelfde
voor ontwikkelen programma's in elke omgeving met elke
gecompileerde taal.
Dit is niet uniek voor c.
Als je java schrijft - een java programma, je gaat de broncode
schrijven, je gaat om de broncode te compileren.
Linken - je bent misschien niet zo op de hoogte van in java, maar het zal een
soort van linken doen en we zullen praten over wat linken is, en dan
ga je het programma uitvoeren.
Je gaat dit allemaal doen.
Wat ik hier beschrijf nogmaals is hoe het is gedaan in c.
Dus bewerken is precies wat je zou denken van wel.
Het is het proces van creëren en het wijzigen
van de eigenlijke code, de c-broncode.
De c-broncode gaat om in een bestand te zijn.
En het gaat alles bevatten de verklaringen en alle
instructies die u schrijft.
Alle c-broncodebestanden eindigen met de . c extensie, en dat is hoe
je kunt identificeren dat het een broncodebestand is.
Daarvoor . c extensie gaat om de basisnaam
te worden genoemd, wilt u dat uw bestandsnamen zinvol zijn.
Als je een c-programma schrijft dat twee optelt, nummers, hebt u mogelijk een bestand
met de naam add. c, die een broncode bevat.
En onthoud dat de meeste c programma's zullen veel verschillende
bestanden hebben.
Dus uw bestanden moeten goede namen hebben.
Maar de manier waarop je je kunt identificeren? c broncode is de . c extensie.
Ze bevatten allemaal de . c extensie.
Wanneer we nu onze code bewerken voor deze les gaan we
een geïntegreerde ontwikkelomgeving gebruiken.
We gaan niet zomaar om een eenvoudige editor te gebruiken.
Een voorbeeld van een eenvoudige editor zou zoiets als wordpad zijn.
We gaan iets gebruiken die een editor heeft maar ook
veel andere dingen heeft die je helpen schrijf uw code efficiënter.
De IDE - en dit wordt een IDE genoemd, geïntegreerde ontwikkelomgeving.
Degene die we gaan gebruiken voor deze les
is Code Blocks, ik ga het in detail behandelen, maar we
gaan codeblokken gebruiken voor de bewerkingstaak.
Maar je kunt gebruiken wat je wilt.
Als u Kladblok wilt gebruiken, als u:
als je iets nog minuscuuls wilt gebruiken, kun je Atom, er is visuele
studio-IDE's, maar degene die we hier gaan behandelen, is hoe om uw code en codeblokken te bewerken.
En dit is een leuk idee en de reden waarom ik ervoor koos, we zullen
het hebben over meer details, maar dat is het wel platformoverschrijdend en gebruiksvriendelijk.
Dus bewerken is de basis proces, het schrijven van de code.
compileren.
We weten wat een compiler doet.
Het duurt gewoon dat hoge niveau taalcode en en converteert deze
naar machinetaal, en het ook detecteert en vindt fouten in uw code.
Nadat je je code hebt bewerkt, ben je de compiler gaan uitvoeren.
Dus de invoer voor de compiler is wordt al
je broncode, al je . c bestanden alles wat u aan het bewerken bent.
En nogmaals, een c-programma kan hebben veel bronbestanden.
Maar de invoer voor de compiler is: deze bronbestanden, de compilatie
zelf converteert deze code is een proces in twee fasen.
De eerste fase heet de voorbewerkingsfase.
Tijdens welke uw code kan worden gewijzigd of aangevuld.
En de tweede fase is de daadwerkelijke compilatie, genereert het
de assembleertaalcode.
En we zullen hier in meer over praten detail, deze voorbewerkingsfase.
Maar je moet het gewoon weten nu er twee fasen zijn
bij het compileren.
Degene waar we ons op gaan focussen of degene die gemakkelijk te begrijpen is,
is het genereren van de objectcode.
Dus de compiler gaat: kijk naar elke uitspraak en
het zal ervoor zorgen dat de syntaxis correct is en dat aan de semantiek
van de taal wordt voldaan.
Syntaxis is om ervoor te zorgen dat de structuur van de code juist is,
dat je puntkomma's hebt bij de einde van
de verklaring, dat u gegevenstypen gebruikt, dat u - u bent volgens de regels van de taal.
Semantiek is de betekenis van de woorden.
Dus als je een if . gebruikt trefwoord, dat is een voorwaarde.
Semantiek gebeurt in de compilatiefase door een symbooltabel
te maken, enzovoort.
Maar de compiler is belangrijk.
Het gaat genereren deze objectcode.
Het zal je vertellen of je fouten in uw syntaxis hebben.
Het kan soms ook herkennen of je wel of geen dode code
hebt waar eigenlijk geen code wordt gebruikt.
Het vindt geen logische fouten.
Het vindt alleen syntaxisfouten.
Nogmaals, syntaxis is de regels en taal.
Logische fouten zijn de betekenis.
Like als je een fout hebt gemaakt in logica kunt u een fout
maken in de functionaliteit.
Zodat uw code kan worden uitgevoerd, kan worden gecompileerd, maar het kan zijn dat het niet werkt zoals bedoeld, en
dit wordt een logische fout genoemd.
De compiler gaat het niet vertellen u als u een logische fout hebt.
Als u de gebruiker om een nummer in plaats van een tekenreeks of u vraagt de gebruiker om
zijn laatste naam voor hun voornaam dat is
een logische fout. Compiler gaat niet om u dat soort fouten te vertellen.
Typische fouten gerapporteerd door de compiler gaan
dingen zijn als niet-gedeclareerde variabelen, expressie dat niet in
overeenstemming is met de syntaxis, je hebt niet het recht haakjes, je kent
blokken die geen eindblokken hebben.
Je wordt heel, zeer bekend met de compilerfouten
en wat ze betekenen.
Hopelijk, nadat je hebt geleerd de c-taal en je voert de compiler
uit, je gaat zien een fout en
u kunt deze onmiddellijk herstellen.
Zeg oeps, een syntaxis vergeten of oeps een puntkomma vergeten,
oh, ik vergat een recht te geven haakje om dat codeblok te beëindigen.
Het wordt een tweede natuur.
Dus nadat je alle fouten en uw
compileren is gelukt, het gaat vertaal in assembler en
genereer deze objectcode.
Dus het eigenlijke object code is een . o bestand.
Het is de eigenlijke samenvatting taalcode die wordt uitgevoerd.
Het heeft een extensie. obj of . O. obj meestal op Windows zal de extensie zijn. o op een Linux of Macintosh systeem zal de extensie zijn.
Je gaat dat bestand zien gegenereerd nadat u uw code hebt gecompileerd.
En dat is nog maar de eindfase
van de compilatie, dat is de eigenlijke assembleertaal.
Het wordt binair, het ziet er niet uit als tekst waar
je niet naar kunt kijken.
Het wordt gewoon een . o extensie, en dat is wat de
compiler genereert.
De manier waarop u de compiler uitvoert in c gebruik je eigenlijk een commando.
U hoeft dit waarschijnlijk
niet te doen veel omdat de ide, de editor in de geïntegreerde ontwikkeling is gaan het voor je doen door gewoon
op een menu-optie te klikken, maar het is belangrijk om te weten wat er speelt.
Dus wanneer u de compiler uitgeeft commando
gebruikt, gebruikt het meestal een GNU-compiler, wat een gcc-commando is.
Maar op het basisniveau ren je gewoon een compilerprogramma ofwel cc of gcc.
Je voert dat programma uit en dan specificeert u de invoer.
Onthoud dat de compiler als invoer van de bronbestanden.
U specificeert de invoer met a -c markeren en vervolgens de
bronbestanden de een na de ander specificeren.
Dus voorbeelden hier zijn cc-cmyprog. c of als je de GNU-compiler gebruikt, een
populaire gcc-c.
En als u de c-vlag weglaat, is uw programma wordt automatisch ook
gekoppeld, wat de volgende stap is.
Maar het is echt gemakkelijk om dat uit te voeren compiler als u zich in
de opdrachtregelinterface bevindt.
Het is nog makkelijker als je gewoon gebruik een menuoptie die we waarschijnlijk in
deze klas zullen doen.
Maar nogmaals, het duurt input, de c source-bestanden.
In codeblokken, zoals ik al zei,
je gaat gewoon op een menu-optie klikken en het zal automatisch een link
compileren en dan kun je op een ander menu klikken optie wordt het automatisch uitgevoerd.
Maar nogmaals, wat is er aan de hand? de kap is dat je
eigenlijk het compiler-commando geeft met de -c vlag en de invoerbronbestanden.
Nadat je hebt gecompileerd, link je. Zoals ik al zei, elke programmeertaal heeft een koppeling,
maar veel vaak is het transparant, je weet niet eens
wat er gebeurt.
In c is het koppelingsproces belangrijk omdat het niet altijd transparant is.
Maar met de meeste moderne
IDE's van tegenwoordig, ja, maar ik moet wel benadrukken dat het belangrijk is in c.
Dus nadat het programma heeft hierin is vertaald. oude code zijn objectcode, het dan is klaar
om te worden gekoppeld.
De reden dat we linken is als
we met externe bibliotheken moeten we al die andere bibliotheken pakken en zet ze in één programma.
Dus linken is gewoon alles krijgen de aanwezige afhankelijkheden en het
bouwen van een daadwerkelijk uitvoerbaar bestand.
Dus de . o bestand zijn de objecten.
Je koppelt dan alle . os in één uitvoerbaar bestand.
En nogmaals, dit is
meestal transparant, gebeurt meestal automatisch wanneer u compileert.
Maar nogmaals, het mag niet en je moet misschien een apart commando
doen, zoals een -l of zoiets.
Maar het duurt al die objecten bestanden en bouwt één uitvoerbaar bestand.
En het uitvoerbare is wat u uitvoert.
Dus het gaat al die dingen combineren.
En dan gaat het ook nog combineren.
En dat heb je misschien. dat zijn extra bibliotheken, die andere programma's die u misschien wilt
gebruiken die iemand anders heeft
geschreven of andere bibliotheken die bij de c-taal horen.
Je gaat alles nemen die en zet ze bij elkaar.
En de koppelingsfase zal ook fouten detecteren en rapporteren.
Het zijn twee aparte fasen.
Koppelen, nogmaals, zou meestal zijn als: herdefinitiefouten of u probeert een functie aan
te roepen die niet bestaat.
Dus als je dat niet hebt. o bestand naar als je het hele programma verzint,
krijg je een koppelingsfout.
En je moet alle . o's.
En nogmaals, de . o's misschien niet eens van jou.
Ze kunnen met dezelfde taal komen, ze kunnen deel uitmaken van de standaardbibliotheek of ze kunnen
met een andere komen programma dat iemand anders heeft geschreven.
Maar die heb je allemaal nodig. o's om één uitvoerbaar bestand te vormen.
Dus programmabibliotheken ondersteunen en de C-taal uitbreiden door routines te bieden om bewerkingen uit te voeren die
geen deel uitmaken van de taal.
Invoer- en uitvoerbibliotheken zijn: bijvoorbeeld wiskundige
bibliotheek, bibliotheken voor tekenreeksmanipulatie.
Dit is precies hetzelfde als je... bekend met het java-programma, is
het hetzelfde als de java-api.
Het is hetzelfde als pakketten.
Het is dit concept van
ik wil schrijf gegevens naar een bestand Ik wil het
niet zelf implementeren, ik ben een bestaande bibliotheek gaan gebruiken die bij de taal wordt geleverd.
Het is nog steeds geschreven in c, het is gewoon iemand c komt daarmee.
Er zijn dus
allerlei soorten verschillende bibliotheken die we gaan leren kennen en gebruiken.
Dit gebeurt onderdeel van de koppelfase.
Een storing dus tijdens de koppelfase
betekent dat je opnieuw terug moet gaan en
je broncode moet bewerken om te maken zeker dat u dat objectbestand
kunt vinden, dus veel van de fouten meestal betekent dat u alleen een bestand of iets dergelijks hoeft op te nemen. Deze wordt ook een tweede natuur.
Succes, als je klaar bent succesvol compileren, u bent klaar met succesvol
koppelen, dat zal een uitvoerbaar bestand produceren.
In een Windows-omgeving, het uitvoerbare
bestand heeft een . exe extensie.
In Linux en Windows zal het: gewoon standaard een. uit.
U kunt de naam van een wijzigen. uit naar iets zinvoller
door gewoon iets mee te geven met het compiler-commando.
Maar de meeste IDE's ook
in codeblokken zal een compileer- en linkprogramma hebben in een
enkele handeling en het zal maak het uitvoerbare bestand en dan kunt u gewoon dubbelklikken op het uitvoerbare bestand of
u kunt het uitvoerbare bestand uitvoeren vanuit een opdracht of vanuit de menuoptie.
Maar nee op het lage niveau als je onder Linux
zie je een a. standaard uit als uw uitvoerbaar bestand. Op Windows zie je een . exe.
Een programma van enige significante omvang zal bestaan uit verschillende broncodebestanden, ik
heb dit eerder vermeld.
Elk broncodebestand heeft de compiler om het objectbestand
te genereren dat moet worden gekoppeld.
Het programma is veel gemakkelijker te beheren door het op te
splitsen in een aantal kleinere bronbestanden.
U zult veel bronnen willen gebruiken bestanden, en u wilt geen
bronbestand dat 5000 regels code bevat.
Dat is niet samenhangend.
Dat is niet eenvoudig te beheren.
Dus je gaat bestanden maken die
broncode bevatten, en de broncode zal specifiek zijn.
Het gaat een hebben specifieke functionaliteit.
Het maakt het veel gemakkelijker om
ontwikkelen en veel gemakkelijker te debuggen en is veel samenhangender.
Dus je gaat hebben veel kleinere bronbestanden.
U wilt geen grote bronbestanden met duizenden regels code.
En al deze bronbestanden zijn om het hele programma te maken.
Ze zullen allemaal hun eigen . o's, en ze worden
allemaal ingevoerd in de compiler.
Al deze concepten die maken van het
programma, worden in wezen ook als een project beschouwd.
Je kunt het zien als dat op een hoger niveau.
Het is jouw project, het is jouw programma.
Nadat je eindelijk alles hebt gedaan dit en je hebt het gekoppeld, je hebt
je uitvoerbare bestand, u kunt het programma vervolgens uitvoeren.
In de meeste IDE's is dit gewoon wordt een
menuklik of u kunt dubbelklikken in vensters, u kunt dubbelklikken op de exe.
En als je Linux gebruikt, je typt gewoon een a. uit.
Wanneer nu een. uit moet je hebben bepaalde machtigingen, dus u moet misschien een opdracht voor wijzigingsmodus geven,
maar om het uit te voeren kun je zeggen . /een. uit en dat zal het programma
uitvoeren vanaf de opdrachtregel Linux.
Maar nogmaals, dat hoeft meestal niet zorgen hierover. Dus de uitvoeringsfase
is waar u uw programma uitvoert.
Elk van de verklaringen van het programma wordt achtereenvolgens uitgevoerd.
Als het programma erom vraagt:
gegevens van de gebruiker, zal het programma pauzeren en die invoer krijgen.
U kunt de invoer krijgen via de toetsenbord of het kan de invoer krijgen via de grafische
gebruikersinterface als u dat hebt: bibliotheken daarvoor in uw c-code.
Resultaten die worden weergegeven door het programma verschijnen
in een venster genaamd de console.
En we gaan het laten zien u voorbeelden hiervan als we
het hebben over codeblokken.
Maar wanneer u uw programma uitvoert, meestal zul je output zien.
Niet altijd, soms zullen programma's dingen doen die geen output opleveren.
Maar meestal produceren ze output en
je ziet de output rechts op de terminal of de console.
De uitvoeringsfase genereert ook een grote verscheidenheid aan foutcondities.
Dus je kunt de verkeerde
produceren output die slechts een logische fout is en je moet teruggaan en bewerk uw broncode.
Het kan daar zitten en gewoon niets doen omdat je logische problemen hebt.
En dan kan het
ten slotte crashen uw computer, wat in het slechtste geval is, wat betekent dat: je
deed iets heel ergs in je programma en
het was zo erg dat het programma net stierf of gewoon
of het eigenlijk andere veroorzaakte programma's op uw besturingssysteem om uw hele computer te laten crashen.
Dus de eigenlijke c-toepassing uitvoeren problemen kunnen veroorzaken. Als het programma de bedoelde functionaliteit, dan moet je teruggaan en de bron
bewerken code die u
mogelijk moet reorganiseren of opnieuw moet ontwerpen en dit is
waar we over de verschillende stappen gesproken.
Dit staat bekend als debuggen fase om uw fouten te vinden en op te lossen.
We gaan een hele hebben
sectie over debuggen omdat het zo belangrijk is.
Die heb ik eerder genoemd van de beste manieren om te leren,
is door je fouten te leren.
Je gaat constant terug en bewerk de broncode en debug.
Het hele proces van samenstellen,
het koppelen en uitvoeren van het programma wordt herhaald totdat u klaar bent,
totdat u hebben alle resultaten die je nodig hebt voor de functionaliteit van die code.
Dus hier is, nogmaals, nog een leuke illustratie die ik graag geef.
Dit komt uit een boek genaamd Beginning C door Horton.
Maar dit is het proces die je gaat hebben.
Je gaat je broncode bewerken.
Je gaat een bestand maken met een . c extensie en een betekenisvolle naam.
Je gaat een editor gebruiken om dat
te doen of een IDE, geïntegreerde ontwikkelomgeving, zoiets als codeblokken.
Je gaat het dan compileren.
De compiler gaat genereer een obj-bestand en een o-bestand.
Als het dat bestand niet
genereert, dat betekent dat je fouten hebt en dat je terug moet gaan om ze op te lossen.
Nadat u de obj-bestanden hebt gemaakt, de objectbestanden, dan moet je ze allemaal aan
elkaar koppelen om een uitvoerbaar bestand te maken.
En je zou ook kunnen hebben fouten in die
fase waarin ze niet goed zijn gekoppeld.
Je moet teruggaan en bewerk uw broncode.
Zodra je eigenlijk geen fouten meer hebt
en je hebt een uitvoerbaar bestand, dan kun je je programma uitvoeren.
En nogmaals, nadat je je programma, kunt u nog steeds fouten hebben omdat er
logische fouten kunnen zijn.
Dus dan zou je teruggaan en bewerk uw broncode.
Dit wordt dus een repetitief
proces waar u heel bekend mee zult zijn.
Bewerken, compileren, koppelen, uitvoeren.
En dit is weer typisch wat je doet in alle talen.
Je gaat dit keer op keer doen en keer op keer
totdat uw programma aan al uw vereisten voldoet.