valamilyen oknál fogva úgy döntöttem, hogy egy terméket egyszerű C-vel készítek. De a személyes növekedés eszközeként azt hiszem, sokkal többet tanultam a programozásról a folyamat során.

például most már pontosabban tudom, miért viselkedik másképp egy python szótár és egy lista, és mit jelent valójában “hivatkozással átadni”.”

Ha azonban lenne egy akadály, amely miatt soha nem akarok visszamenni a C-be, az a rettegett “szegmentációs hiba 11” lenne, amelyet szorosan követ a “megszakítás csapda 6.”

Ez a két hiba futási idő alatt fordul elő, ami megnehezíti a hibakeresést. Az XCode, az Eclipse vagy más hibakeresési eszközök valóban hasznosak, de megtanultam, hogy sokkal fontosabb megtanulni ezeket a dolgokat, és kidolgozni a hibakeresési folyamat kezelésére szolgáló eljárásokat. Ez csak a jegyzeteim a saját gyakori hibáimról. Remélem, hogy ez egy hibaelhárítási lista mindenkinek, akinek saját problémái vannak. Azt akarom, hogy legalább fedezze a hülye problémák, így összpontosítani valódi kódolási problémák.

a szegmentálási hiba azt jelenti, hogy a program megpróbált hozzáférni valamihez, amit nem kellett volna. Ez is része a problémának. Sok oka van annak, hogy egy program hozzáférhet olyan dolgokhoz, amelyeket nem kellene, de a lefordított kód nagyjából csak azt mondja: “#$#@^*&!”helyette. Ha belegondolsz, akkor nem akarja, hogy meg kell magyarázni, hogy valaki miért dugta meg egy érzékeny helyen teszi őrült. Csak azt akarod, hogy hagyják abba. Szerencsére a számítógépek mind buták, mind meglepően türelmesek körülbelül 75 év mérnöki munka után. Folyamatosan küldenek seg hibákat, de (általában) nem hagyják abba a barátságot, miután ez megtörténik Az 1000.alkalommal.

mi az abortusz csapda?

Ez nem sokban különbözik. Valahol a számítógépe azt mondta magának, hogy szakítsa meg a programot. Ismét nem túl hasznos. Ez azonban általában akkor fordul elő, amikor megpróbál valami olyasmit elérni, mint a string egy kétkaros karakterlánc "nw" vagy nem sikerül elegendő memóriát lefoglalni char string egy olyan karakterlánchoz vagy tömbhöz, mint "way".

mit kell tennie egy Seg hibával?

az általam olvasott oktatóanyagok általában a hibakereső eszközök, például az lldb, a gdb stb. Ez mind szép és pompás. Igen, először a gcc -g parancsot kell futtatnia, majd a lldb executable_name parancsot, majd a run -flag1 -flag2 parancsot, hogy lássa, ez segít-e kitalálni. De néha nincs segítség. Van egy lista a dolgokról, hogy ellenőrizze, bár.

• ellenőrizze, hogy a szükséges program globális változóinak vannak-e értékei. Ez leginkább azért történt, mert olyan zászlókat hoztam létre, amelyek kitöltöttek egy csomó értéket, amelyeket be kell állítani a futás előtt. Mi van azonban, ha nem tesznek semmit? Seg Hiba 11! Számos alkalommal azt hittem, hogy a vars-t akkor állították be, amikor nem voltak, és ez kihívást jelentett a hibákra. Még jobb, próbálja tartani globals egy határt, így könnyebb nyomon követni.
• malloc mind a barátod, mind az ellenséged. Különösen a felhasználói bejegyzéseknél nagyon nehéz lehet memóriát lefoglalni, majd másolni, összefűzni és bármi mást megtenni az úton. Jól ismeri ezt a parancsot, és hogyan működik. És ne felejtsd el free() a memória, ha kész!
• achar var használatával határozhatja meg a memória kiosztásához szükséges karakter* méretét. A probléma nagy részében változók hozzárendelésével foglalkoztam, hogy végül elfogadjak egy karakterláncot. Láttam más tanácsot, de ha ez egy string dolgozik, azt hiszem, volt strlen() dolgozott a legkövetkezetesebben. Szüksége van a +1-re a \0 (null) számára, hogy befejezze a karakterláncot a végén.
• használja aint arr) +1)] más típusú tömbökhöz. Ez egy furcsa módja annak, hogy a dolgokat, de ez az, amit kap egy alacsony szintű nyelv.
• \0 null értéket jelöl, és egy tömböt zár le. Hasznos lehet, ha megpróbálja megakadályozni a puffer túlcsordulási problémákat.
• próbálja meg a megadott állandókat a lehető legnagyobb mértékben használni. Amikor meg tudja határozni a dolgokat előre lefordítani, akkor menteni hibakeresés időt később.
• értsd meg, mire szolgálnak a fejlécfájlok. Sok oktatóanyag megmondja, hogy mit tartalmaz a fejlécfájl, de nem mindig világos, hogy mire szolgálnak. A fejlécfájlok a fordítás előtti időben kerülnek rögzítésre, és összefoglalják a változókat és a függvényeket, amelyek a program rendelkezésére állnak *mielőtt lefordítanák*. Ez azt jelenti, hogy a .a programban szereplő c fájlok hozzáférhetnek ezekhez a funkciókhoz, feltéve, hogy a #include <headerfile.h> hozzáadódik a fájlhoz. Egy jó egyezmény az, hogy hozzon létre egy .h Fájl, amikor létrehoz egy .
• a legtöbb hurok így megy: for (int i=0; i < stop; i++) egy egyszerű módja annak, hogy egy megszakítási csapdát, hogy egy 6 előtt stop.
• tartsa a problémákat. Próbáld meg úgy csinálni, hogy minden fájl néhány diszkrét dolgot csináljon, semmi mást. Ha különböző fájlokon keresztül kell vadásznia, akkor nagyon nehéz lehet megtalálni a seg hibaproblémáit.
• a számítógépes matematika nehéz. Nem igazán, de a kis dolgok nagy problémákat okoznak. char variable például két elemet tartalmazó tömböt jelent, de mivel az indexek 0-nál kezdődnek, ez azt jelenti, hogy csak az 1-es számra léphet.
• a formátum karakterláncok nyomtatása megfelelő típusként. Szerencsére ez általában fordításkor elakad, de továbbra is problémákat okozhat. Győződjön meg arról, hogy a %{whatever} formátumkarakter megfelel bármilyen változónak, amelyet bele kíván tenni.

Ez minden, amim van. Remélem, a nyomorúságaim megmentettek néhány fejfájást az úton! Ha minden más kudarcot vall, most van egy listám azokról a dolgokról, amelyeket ellenőrizni kell, mielőtt kihúzom a hajam!