af en eller anden grund besluttede jeg at bygge et produkt ved hjælp af almindelig C. Hvis målet var kodeeffektivitet, var det en katastrofe. Men som et værktøj til personlig vækst tror jeg, jeg lærte meget mere om programmering i processen.

for eksempel ved jeg nu mere præcist, hvorfor en python-ordbog og en liste opfører sig anderledes, og hvad det virkelig betyder at “passere ved reference.”

men hvis der var en barriere, der ville få mig til aldrig at gå tilbage til C, ville det være den frygtede “segmenteringsfejl 11”, fulgt tæt af “Afbryd fælde 6.”

disse to fejl opstår i løbet af køretiden, hvilket gør dem vanskelige at debugge. Eclipse eller andre fejlfindingsværktøjer er virkelig nyttige, men jeg har lært, at det er meget vigtigere at lære, hvad disse ting er, og komme med procedurer til at tackle fejlfindingsprocessen. Dette er bare mine noter om mine egne almindelige fejl. Jeg håber at gøre dette til en fejlfindingsliste for alle, der har deres egne problemer. Jeg vil i det mindste dække mine dumme problemer, så du kan fokusere på reelle kodningsproblemer.

en segmenteringsfejl betyder, at dit program forsøgte at få adgang til noget, det ikke skulle. Det er en del af problemet. Der er mange grunde til, at et program kan få adgang til ting, det ikke skal, men kompileret kode siger stort set bare “#$#@^*&!” derimod. Hvis du tænker over det, du ønsker ikke at skulle forklare nogen, hvorfor de stikker dig på et følsomt sted, gør dig sur. Du vil bare have dem til at stoppe med at gøre det. Heldigvis er computere både dumme og overraskende tålmodige efter omkring 75 års teknik. De vil fortsætte med at sende Seg-fejl, men (normalt) vil ikke stoppe med at være venner, efter at det sker 1000.gang.

Hvad er Abortfælde?

det er ikke så meget anderledes. Et eller andet sted fortalte din computer sig selv at afbryde programmet. Igen, ikke meget nyttigt. Det sker dog normalt, når du forsøger at gøre noget som adgang string af en to-char streng "nw" eller undlader at allokere nok hukommelse char string for en streng eller array som "way".

Hvad skal du gøre med en seg-fejl?

de tutorials, jeg læser, har tendens til at fokusere på at bruge fejlfindingsværktøjer som lldb, gdb og så videre. Det er fint og dandy. Ja, du skal køre gcc -g først og derefter lldb executable_name og derefter run -flag1 -flag2 for at se, om det hjælper dig med at finde ud af det. Men nogle gange er der ingen hjælp overhovedet. Jeg har dog en liste over ting at kontrollere.

• Kontroller, at dine nødvendige program globale variabler har værdier. Dette skete for det meste, fordi jeg havde oprettet flag, der udfyldte en masse værdier, der skulle indstilles, før jeg kørte. Men hvad nu hvis de ikke lægger noget i? Seg Fejl 11! Der var et antal gange, jeg * troede * vars blev indstillet, da de ikke var, og det gjorde det til udfordrende bugs. Endnu bedre, prøv at holde globals til en grænse, så de er lettere at spore.malloc er både din ven og din fjende. Især med brugerindgange kan det være meget udfordrende at allokere hukommelse og derefter kopiere, sammenkæde og gøre hvad der ellers er nede ad vejen. Kend denne kommando godt, og hvordan den fungerer. Og glem ikke at free() hukommelsen, når du er færdig!
• brug char var til at bestemme størrelsen på en char* til hukommelsesallokering. Det meste af det problem, jeg havde involveret at tildele variabler til sidst at acceptere en streng. Jeg har set andre råd, men hvis det er en streng, du arbejder med, tror jeg, at strlen() arbejdede mest konsekvent. Du har brug for +1 til \0 (null) for at afslutte strengen i slutningen.
• brug int arr) +1)] til arrays af andre typer. Det er en underlig måde at gøre tingene på, men det er hvad du får med et sprog på lavt niveau.
• \0 repræsenterer null og vil afslutte et array. Det kan være nyttigt, når du forsøger at forhindre bufferoverløbsproblemer.
• prøv at bruge definerede konstanter så meget som muligt. Når du er i stand til at definere ting på precompile, vil det spare dig debugging tid senere.
• forstå, hvad header-filer er til. Mange af tutorials vil fortælle dig, hvad en headerfil indeholder, men det er ikke altid klart, hvad de er til. Header filer er fanget på forhånd kompilere tid og give en oversigt over variabler og funktioner til rådighed for programmet *før det kompilerer*. Det betyder, at .c-filer inkluderet i programmet vil kunne få adgang til disse funktioner, forudsat at #include <headerfile.h> føjes til filen. En god konvention er at skabe en .H fil, når du opretter en .C-fil, og inkluder den i c.
• mest for loops går sådan: for (int i=0; i < stop; i++) en nem måde at få en abortfælde på er at sætte en larp foran stop.
• Hold dine problemer indeholdt. Prøv at gøre det, så hver fil gør et par diskrete ting og intet andet. Hvis du skal jage gennem forskellige filer igen og igen, kan det gøre det svært at finde dine seg-fejlproblemer.
• Computer matematik er svært. Det er ikke rigtig, men små ting forårsager store problemer. char variable for eksempel betyder et array, der indeholder to elementer, men fordi indekser starter ved 0, betyder det, at du kun kan gå op til nummer 1.
• Udskriv formatstrenge som den rigtige type. Heldigvis bliver dette normalt fanget på kompileringstidspunktet, men det kan stadig forårsage problemer. Sørg for, at dit formatkarakter %{whatever} passer til den variabel, du vil lægge i den.

det er alt, hvad jeg har for nu. Jeg håber, at mine elendigheder har sparet dig nogle hovedpine nede ad vejen! Hvis alt andet fejler, har jeg nu en liste over ting at kontrollere, før jeg trækker mit hår ud!