Hallo, en welkom terug.
In deze lezing wil ik enkele veelvoorkomende compilers en waarschuwingen bespreken.
We hebben het gehad over enkele veelvoorkomende c-problemen.
Maar soms weet je niet eens dat je die fouten in je programma hebt als
de compiler je dat probeert te vertellen.
Compilerfouten en waarschuwingen zijn vaak erg cryptisch voor nieuwe programmeurs.
Ze vertellen je misschien dat je een puntkomma mist, maar er staat onbereikbaar einde van de instructie.
En voor iemand die nieuw is, weten ze misschien niet eens wat dat betekent.
Het vergt dus veel oefening om veel code te schrijven en
om sommige van deze compilerwaarschuwingen in de loop van de tijd te ontcijferen.
Maar daarvoor wil ik je wel even op de hoogte stellen.
Dus enkele van de veelvoorkomende problemen die je in de vorige lezing
hebt gezien, ik ga enkele van de compilerwaarschuwingen en -fouten beschrijven en wat het daadwerkelijk zal zeggen.
Het is heel, heel belangrijk om je te vertellen om te begrijpen wat de compiler je vertelt.
Als de compiler je die fouten vertelt, maar je begrijpt die fout niet,
zal het veel langer duren om die code te herstellen.
Maar als je de fout ziet en je weet precies wat er staat, kun je
het in een mum van tijd gaan repareren.
Ik herinner me dat ik in het lab was toen ik voor
het eerst begon met programmeren, en
ik zou een puntkomma missen, iets heel gewoons. En de compiler zou me vertellen dat ik een puntkomma mis,
maar dat zou ik niet
weten, het zou gewoon onbereikbaar einde van de verklaring zeggen, en ik zou zeggen,
wat betekent dat, wat is een verklaring. Ik zou erg in de war zijn.
Daarom wilde ik je wat tips geven over wat de compiler je eigenlijk probeert te vertellen.
Het is dus erg moeilijk te begrijpen waar de compiler over klaagt.
Het ontcijferen van deze berichten
is soms erg verwarrend.
Dus je moet deze compilerfouten begrijpen om ze op te lossen, vrij eenvoudig.
En de compiler doet het halve werk voor je.
Het controleert de syntaxis en vertelt u precies wat er mis is,
dus u zou dat in uw voordeel moeten gebruiken.
Maar soms is het moeilijk om precies te begrijpen wat er wordt gezegd, vooral als je
nieuw bent en een deel van de terminologie niet begrijpt.
De compiler neemt beslissingen over het vertalen van uw code die de
programmeur niet in de code heeft geschreven.
Dit is handig voor het programma en de compiler,
zodat het beknopter geschreven kan worden.
En alleen ervaren programmeurs profiteren van deze functie.
Dus wat ik je zeg, is dat wanneer je compileert,
je altijd de dash wall-optie moet gebruiken.
Dit gaat alles aan.
Dus soms is een meer geavanceerde functie dat
je wat dingen
eruit haalt, de vertaling een beetje efficiënter maakt.
Maar als je dat
toevoegt, zorg je ervoor dat het programma anders wordt gecompileerd.
En als gevolg daarvan kunt u waarschuwingen in uw code hebben waarvan u niets weet.
Dus de reden dat ik je dat vertel, is dat je altijd wilt compileren met een
bepaalde optie, namelijk de dash wall-optie.
En dat staat eigenlijk standaard aan in codeblokken.
En dit zal u op de hoogte stellen van alle gevallen waarin de
compiler dingen doet waar u geen weet van heeft.
Het zal ook alle waarschuwingen aanzetten,
je veel informatie geven, het is een erg handige compiler-optie.
Als je die optie eenmaal hebt ingeschakeld, kun je
proberen om je beter te helpen begrijpen wat de compiler je vertelt.
Dus de compiler zal je twee soorten
problemen laten zien. Een daarvan is een fout.
Dit zal daadwerkelijk voorkomen dat het programma wordt gemaakt.
U hebt een syntaxisfout en het programma kan niet worden gecompileerd.
Geen uitvoerbaar
werk opnieuw gemaakt en. Meestal, als je fouten van de compiler ziet, wil
je je altijd concentreren op die eerste fout.
Dat is de meest betrouwbare
fout omdat sommige van de andere fouten het gevolg kunnen zijn van die eerste fout.
Focus dus altijd op die eerste fout. Los eerst de fouten bovenaan op
en compileer dan opnieuw en kijk of de andere fouten verdwijnen.
Waarschuwingen. Waarschuwingen zijn berichten die de
compiler laat zien voor speciale situaties en waarin een soort anomalie is gedetecteerd.
Het zijn niet-fatale fouten. Dus het uitvoerbare bestand wordt gemaakt.
Maar het is nog steeds iets dat je moet oplossen.
Een waarschuwing is er met een reden. Je doet iets niet goed of
het kan in de toekomst een probleem veroorzaken.
U wilt dus altijd al uw waarschuwingen oplossen.
En door te compileren met de dash
wall-optie, vind je het programma pas correct als alle waarschuwingen zijn geëlimineerd.
De compilatie zal dus niet mislukken. Dit is waarom ik je
zeg om deze optie te gebruiken en om alles te zien wat er door de compiler gebeurt.
Dus enkele van de meest voorkomende compiler-berichten die je zult tegenkomen, en
dit zal direct gerelateerd zijn aan enkele van de meest voorkomende c-problemen
die we eerder noemden.
Als een variabele niet gedeclareerd is, ziet u deze berichtvariabele eerst niet
gedeclareerd met deze functie.
Dit is een van de meest voorkomende en meestal gemakkelijker te detecteren.
En dan zal het ook het symbool
voor dit bericht weergeven.
Het zal in feite zeggen
dat je deze variabele probeert te gebruiken, maar je hebt het nooit echt gedeclareerd.
We weten dat wanneer u een variabele declareert, u het gegevenstype opgeeft.
U kunt gegevens niet zomaar ondertekenen bij variabelen die niet bestaan.
Een waarschuwing impliciete functiedeclaratie, dit is gerelateerd aan de functiedeclaraties.
Dit is wanneer u een functie probeert aan te roepen, maar
als er geen implementatie aan de functie is gekoppeld. U heeft de koptekst niet opgenomen of
u heeft deze niet aangegeven. Dus het weet niet waar het is,
en het weet niet hoe de functie wordt gedeclareerd, het kent de argumenten niet, het kent de geretourneerde waarde niet.
Heeft u geen informatie over de functie zelf?
Om dit op te lossen, declareert u altijd bovenaan een functie-prototype.
Een andere waarschuwing, namelijk dat de waarschuwingsbesturing het einde van de niet-ongeldige functie bereikt, zal
gebeuren wanneer een functie is gedefinieerd als het retourneren van een resultaat, het is niet-ongeldig,
maar er is geen retourinstructie opgenomen in de functie.
U bent dus vergeten de gegevens terug te sturen.
Ofwel is de functie onjuist gedefinieerd waarbij u het gegevenstype vóór de
functiedeclaratie moet verwijderen, of u bent vergeten die
return-instructie toe te voegen. Een van de andere moet
worden gewijzigd om deze waarschuwing op te lossen.
Maar je ziet hoe dit een waarschuwing is. Je kunt daar nog steeds
compileren, maar man, dat kan echt snijproblemen veroorzaken in je programma.
Als je verwacht dat een functie iets teruggeeft en dat is niet zo, dan wil je
je waarschuwingen ongebruikte variabele nog een veelvoorkomende waarschuwing corrigeren.
Dit wordt afgedrukt door de compiler wanneer een variabele wordt gedeclareerd, maar het wordt nooit gebruikt.
U zou een variabele niet moeten declareren als u deze
niet gebruikt, dus verwijder die declaratie.
Ik heb de neiging om deze nogal wat te krijgen als ik een aantal van mijn
demo's doe, omdat ik variabelen laat die ik nooit gebruik.
Of toen ik demonstreerde hoe ik een variabele declareerde en het vervolgens
compileerde om je te laten zien dat het gecompileerd was, kreeg ik een waarschuwing dat het nooit werd gebruikt.
Dus dat is oké, want ik demonstreerde iets. Maar verwijder uw
variabelen als ze niet worden gebruikt. U hoeft niet te declareren.
Onbepaalde verwijzing naar. Dit gebeurt in de koppelfase.
Dus onthoud de compiler of de compilatiefase, deze zal compileren.
Eerst zal het de preprocessor uitvoeren, dan zal het de objectbestanden genereren en dan zal het die objectbestanden
nemen en ze aan elkaar koppelen om een compleet programma te maken.
Dus tijdens de koppelingsfase
moet het eventuele externe afhankelijkheden oplossen.
Of specifiek alle functies die u aanroept, ze
moeten ergens worden geïmplementeerd.
Dus als het dat objectbestand niet heeft, krijg je dit probleem.
U probeert een functie aan te roepen, maar we hebben er geen code voor.
U moet er dus voor zorgen dat u
naar dit bestand linkt.
Meestal gebeurt de koppeling voor
u, maar in GCC kunt u gewoon de optie streepje l gebruiken
om het koppelingsbestand toe te voegen. Dus als je een functie in
het wiskunde-headerbestand gebruikt, maar je linkt niet naar het wiskundige objectbestand, krijg je deze foutmelding.
En het gebeurt ook als je een gebruiker hebt gedefinieerd
en je hebt geen c-bronbestand toegevoegd.
Je hebt dus meerdere c-bronbestanden.
Een van de c-bronbestanden implementeert deze functie.
Een ander c-bronbestand bevat de header en roept
het aan, maar
u hebt nooit het andere c-bronbestand met de implementatie gecompileerd, u zult
deze fout zien.
Zorg er dus voor dat je dat bronbestand meeneemt, zorg ervoor
dat je alle standaard bibliotheekbronbestanden meeneemt als dat expliciet nodig is, meestal hoef je dat niet te doen.
Een andere veelvoorkomende fout is wanneer er conflicterende typen voor zijn.
Dit is wanneer je een functie-prototype daadwerkelijk hebt gedefinieerd of gedeclareerd en toen je het ging
implementeren, was het niet hetzelfde als hoe je het had gedeclareerd.
Het prototype heeft bijvoorbeeld een resultaattype en naam van haakjes voor de parameters
en vervolgens een puntkomma.
En wanneer u de implementatie
definieert, hebt u een andere werkelijke functiekop.
U heeft een ander retourtype of u heeft een ander aantal parameters.
En dit zegt goed, hé, je
hebt deze ene functieverklaring. En als je het hieronder gaat implementeren, is het compleet anders.
Er is dus een mismatch.
En dit zal je op de regel laten zien dat het conflict voorkomt
in de vorige definitie die de tegenstrijdigheid veroorzaakte.
Dus in de implementatie is het meestal waar het je de regel laat
zien, omdat je meestal je functies bovenaan declareert.
Runtime-fouten. Runtime-fouten zijn problemen in uw code
die optreden wanneer u het programma uitvoert, niet wanneer u het compileert.
Dus dit zijn
meestal crashes of het zijn de niet-fatale fouten
waarbij je buiten de grenzen zit of iets dergelijks.
Als het programma draait, heb je een soort logische fout.
Dus de uitvoering van c-programma's kan abrupt eindigen met een crash wanneer een runtime-fout
wordt gedetecteerd, iets wat het niet aankan. Er is een geheugenbeschadiging, zoals
ik al zei.
Out-of-bounds-fouten zorgen er meestal voor dat programma's vastlopen.
Meestal zie je een segmentatiefout.
En segmentatiefout zegt eigenlijk niets.
Dus wat u meestal wilt doen om dit probleem verder te diagnosticeren,
is kijken naar de call-stack, zoals
ik al eerder zei, het programma crasht regel voor regel
om te zien welke regel de crash veroorzaakt.
Je kunt de call-stack krijgen als er een kernbestand is, dat ik eerder noemde.
En dan kun je vanuit de call-stack zien welke lijn crasht.
Of beter nog, voer de debugger uit, stap voor stap en als je een regel uitvoert,
debugger, zie je het programma crashen en kun je het op die manier identificeren.
Dit zijn dus gewoon weer wat meer
tips over compilerfouten en waarschuwingen en berichten en hoe deze te interpreteren.
Er zijn eigenlijk
links online. Of als
je googled, zal het je elke compilerfout en waarschuwing vertellen die
kan worden geproduceerd en het zal in feite een definitie
geven van waarom dit is geproduceerd en
wat in wezen het probleem was.
Want nogmaals, die compileerfouten kunnen erg cryptisch zijn.
En zelfs dat ene woord zei
onbereikbare controle. Je weet uit die beschrijving noodzakelijkerwijs,
tenzij je dat hebt ervaren, dat betekent dat je nooit iets van een functie terugkrijgt.
Maar als je dat doet, een van de beste manieren om problemen in
je programma te vinden en op te lossen als je compilerfouten hebt en je die
compiler niet begrijpt, google het dan. En wat er meestal zal gebeuren, is dat je naar stack overflow gaat.
En het zal je vertellen dat dit jouw fout is, dit is hoe
je het oplost. Dat doe ik tot op de dag van vandaag.
Ik programmeer al 15 jaar in c, maar er zijn nog steeds
momenten waarop ik dingen tegenkom, en ik vraag me af wat dit precies betekent.
En ik zal het googlen, ik neem de compiler, zet het tussen aanhalingstekens en het
zal me precies vertellen wat er gebeurt.
Stack overflow is een heel, heel goede website.
En het kan echt veel tijd besparen
in het foutopsporingsproces. Probeer niet alleen te raden wanneer u compilers of waarschuwingen ziet.
Die compiler probeert je iets te vertellen en zal precies aangeven wat er aan de hand is.
Dus als u het begrijpt, kunt u uw probleem veel, veel sneller oplossen.
En als het niet iets is waar je
bekend mee bent, ga dan naar stack overflow of ga naar een website die ze allemaal beschrijft
en je kunt het op die manier ontcijferen.
Ik hoop dat dit nuttig was. Dank u.