c errors undefined reference
stemmeskiftere, der arbejder med uenighed
Denne vejledning beskriver de kritiske fejl, som programmører ofte støder på i C ++ som Udefineret reference, en segmenteringsfejl (kernedumpet) og uløst eksternt symbol:
Vi vil diskutere de vigtigste fejl, som vi ofte støder på i C ++, der faktisk er lige så kritiske. Bortset fra system- og semantiske fejl og undtagelser, der opstår fra tid til anden, får vi også andre kritiske fejl, der påvirker driften af programmer.
Disse fejl opstår for det meste i slutningen af programmet ved kørsel. Nogle gange giver programmet korrekt output, og så opstår fejlen.
=> Besøg her for at lære C ++ fra bunden.
Hvad du vil lære:
Vigtige C ++ fejl
I denne vejledning diskuterer vi tre typer fejl, der er kritiske set fra enhver C ++ programmørs synspunkt.
- Udefineret reference
- Segmenteringsfejl (kerne dumpet)
- Uløst eksternt symbol
Vi vil diskutere de mulige årsager til hver af disse fejl og sammen med de forholdsregler, vi kan tage som programmør for at forhindre disse fejl.
Lad os begynde!!
Udefineret reference
En “udefineret reference” -fejl opstår, når vi har en henvisning til objektnavnet (klasse, funktion, variabel osv.) I vores program, og linkeren kan ikke finde sin definition, når den forsøger at søge efter det i alle de sammenkædede objektfiler og biblioteker .
Når linkeren således ikke kan finde definitionen af et linket objekt, udsender den en 'udefineret reference' -fejl. Som det fremgår af definitionen, opstår denne fejl i de senere stadier af sammenkædningsprocessen. Der er forskellige årsager, der forårsager en 'udefineret reference' -fejl.
Vi diskuterer nogle af disse grunde nedenfor:
# 1) Ingen definition angivet til objektet
Dette er den enkleste grund til at forårsage en 'udefineret reference' -fejl. Programmøren har simpelthen glemt at definere objektet.
Overvej følgende C ++ - program. Her har vi kun specificeret prototypen for funktionen og derefter brugt den i hovedfunktionen.
#include int func1(); int main() { func1(); }
Produktion:
Så når vi kompilerer dette program, udstedes linkerfejlen, der siger 'udefineret reference til 'func1 ()''.
For at slippe af med denne fejl retter vi programmet som følger ved at give definitionen af funktionen func1. Nu giver programmet den passende output.
#include using namespace std; int func1(); int main() { func1(); } int func1(){ cout<<'hello, world!!'; }
Produktion:
Hej Verden!!
# 2) Forkert definition (underskrifter stemmer ikke overens) af anvendte objekter
Endnu en anden årsag til 'udefineret reference' -fejl er, når vi angiver forkerte definitioner. Vi bruger ethvert objekt i vores program, og dets definition er noget andet.
Overvej følgende C ++ - program. Her har vi ringet til func1 (). Dens prototype er int func1 (). Men dens definition stemmer ikke overens med prototypen. Som vi ser, indeholder definitionen af funktionen en parameter til funktionen.
Således når programmet er kompileret, er kompileringen vellykket på grund af prototype og funktionsopkaldsmatch. Men når linkeren prøver at linke funktionsopkaldet med sin definition, finder den problemet og udsteder fejlen som 'udefineret reference'.
#include using namespace std; int func1(); int main() { func1(); } int func1(int n){ cout<<'hello, world!!'; }
Produktion:
For at forhindre sådanne fejl krydser vi blot, om definitionerne og brugen af alle objekterne stemmer overens i vores program.
# 3) Objektfiler er ikke korrekt forbundet
Dette problem kan også give anledning til den 'udefinerede reference' -fejl. Her kan vi have mere end en kildefil, og vi kan kompilere dem uafhængigt. Når dette er gjort, er objekterne ikke sammenkædet ordentligt, og det resulterer i 'udefineret reference'.
Overvej følgende to C ++ - programmer. I den første fil bruger vi funktionen “print ()”, der er defineret i den anden fil. Når vi kompilerer disse filer separat, giver den første fil 'udefineret reference' til udskrivningsfunktionen, mens den anden fil giver 'udefineret reference' til hovedfunktionen.
int print(); int main() { print(); }
Produktion:
int print() { return 42; }
Produktion:
Måden at løse denne fejl er at kompilere begge filerne samtidigt ( For eksempel, ved hjælp af g ++).
Bortset fra de allerede diskuterede årsager kan 'udefineret reference' også forekomme på grund af følgende årsager.
# 4) Forkert projekttype
Når vi angiver forkerte projekttyper i C ++ IDE'er som det visuelle studie og prøver at gøre ting, som projektet ikke forventer, så får vi 'udefineret reference'.
# 5) Intet bibliotek
Hvis en programmør ikke har specificeret biblioteksstien korrekt eller helt glemt at specificere den, får vi en 'udefineret reference' for alle de referencer, programmet bruger fra biblioteket.
# 6) Afhængige filer kompileres ikke
En programmør skal sørge for, at vi på forhånd kompilerer alle afhængighederne i projektet, så når vi kompilerer projektet, finder kompilatoren alle afhængigheder og kompilerer med succes. Hvis nogen af afhængighederne mangler, giver compileren 'udefineret reference'.
Bortset fra årsagerne diskuteret ovenfor kan den 'udefinerede reference' -fejl forekomme i mange andre situationer. Men bundlinjen er, at programmøren har fået tingene forkert, og for at forhindre denne fejl skal de rettes.
hvad man skal gøre med en bin-fil
Segmenteringsfejl (kerne dumpet)
Fejlen 'segmenteringsfejl (kernedumpet)' er en fejl, der indikerer hukommelseskorruption. Det sker normalt, når vi prøver at få adgang til en hukommelse, der ikke tilhører programmet.
Her er nogle af grundene, der forårsager fejl i segmenteringsfejl.
# 1) Ændring af den konstante streng
Overvej følgende program, hvor vi har erklæret en konstant streng. Derefter prøver vi at ændre denne konstante streng. Når programmet udføres, får vi den fejl, der vises i output.
#include int main() { char *str; //constant string str = 'STH'; //modifying constant string *(str+1) = 'c'; return 0; }
Produktion:
# 2) Dereferencing-markør
En markør skal pege på en gyldig hukommelsesplacering, før vi foretager en forskel. I nedenstående program ser vi, at markøren peger på NULL, hvilket betyder, at hukommelsesplaceringen, den peger på, er 0, dvs. ugyldig.
Derfor forsøger vi faktisk at få adgang til dets ukendte hukommelsesplacering, når vi afviger det i næste linje. Dette resulterer faktisk i en segmenteringsfejl.
#include using namespace std; int main() { int* ptr = NULL; //here we are accessing unknown memory location *ptr = 1; cout << *ptr; return 0; }
Produktion:
Segmenteringsfejl
Det næste program viser en lignende sag. Også i dette program peger markøren ikke på gyldige data. En uinitialiseret markør er lige så god som NULL og peger derfor også på ukendt hukommelsesplacering. Således når vi forsøger at afvige det, resulterer det i en segmenteringsfejl.
#include using namespace std; int main() { int *p; cout<<*p; return 0; }
Produktion:
Segmenteringsfejl
For at forhindre sådanne fejl skal vi sikre, at vores markørvariabler i programmet altid peger på gyldige hukommelsesplaceringer.
# 3) Stakoverløb
Når vi har rekursive opkald i vores program, spiser de al hukommelsen i stakken og får stakken til at løbe over. I sådanne tilfælde får vi segmenteringsfejl, da løb tør for stackhukommelse også er en slags hukommelseskorruption.
Overvej nedenstående program, hvor vi beregner faktoren for et nummer rekursivt. Bemærk, at vores basistilstand tester, om tallet er 0 og derefter returnerer 1. Dette program fungerer perfekt for positive tal.
Men hvad sker der, når vi faktisk overfører et negativt tal til en faktorfunktion? Da basistilstanden ikke er angivet for de negative tal, ved funktionen ikke, hvor den skal stoppes, og resulterer således i et stackoverløb.
Dette vises i output nedenfor, der giver segmenteringsfejl.
#include using namespace std; int factorial(int n) { if(n == 0) { return 1; } return factorial(n-1) * n; } int main() { cout< Produktion:
Segmenteringsfejl (kerne dumpet)
For at løse denne fejl ændrer vi nu grundtilstanden lidt og specificerer også sagen for negative tal som vist nedenfor.
#include using namespace std; int factorial(int n) { // What about n <0? if(n <= 0) { return 1; } return factorial(n-1) * n; } int main() { cout<<'Factorial output:'< Produktion:
Faktorisk output: 1
Nu ser vi, at segmenteringsfejlen er taget hånd om, og programmet fungerer fint.
Uløst eksternt symbol
Det uløste eksterne symbol er en linkerfejl, der indikerer, at det ikke kan finde symbolet eller dets reference under sammenkædningsprocessen. Fejlen ligner 'udefineret reference' og udstedes ombytteligt.
Vi har angivet to tilfælde nedenfor, hvor denne fejl kan opstå.
# 1) Når vi henviser til en strukturvariabel i programmet, der indeholder et statisk medlem.
#include struct C { static int s; }; // int C::s; // Uncomment the following line to fix the error. int main() { C c; C::s = 1; }
Produktion:

I ovenstående program har struktur C et statisk medlem, der ikke er tilgængeligt for de eksterne programmer. Så når vi prøver at tildele det en værdi i hovedfunktionen, finder linkeren ikke symbolet og kan resultere i et 'uløst eksternt symbol' eller 'udefineret reference'.
qa tester interview spørgsmål og svar
Måden at rette denne fejl på er at eksplicit omfatte variablen ved hjælp af '::' uden for main, før du bruger den.
# 2) Når der er henvist til eksterne variabler i kildefilen, og vi ikke har knyttet de filer, der definerer disse eksterne variabler.
Denne sag demonstreres nedenfor:
#include #include using namespace std; extern int i; extern void g(); void f() { i++; g(); } int main() {}
Produktion:

Generelt, i tilfælde af et 'uløst eksternt symbol', kan den kompilerede kode for ethvert objekt som en funktion ikke finde et symbol, som det henviser til, måske fordi dette symbol ikke er defineret i objektfilerne eller nogen af bibliotekerne angivet til linkeren.
Konklusion
I denne vejledning diskuterede vi nogle større fejl i C ++, der er kritiske og kan påvirke programflowet og måske endda resultere i et applikationsnedbrud. Vi udforskede alt om segmenteringsfejl, uløst eksternt symbol og udefineret reference i detaljer.
Selvom disse fejl kan opstå når som helst, ved vi af de årsager, vi diskuterede, at vi let kan forhindre dem ved nøje at udvikle vores program.
=> Læs gennem Easy C ++ træningsserien.
Anbefalet læsning