Kõrbes nimega C

Olen oma rännakutega jõudnud vist kõrbefaasi.
(kõrbenud faasi).
Sellest ja teistest faasidest kirjutatase hästi siin:
https://www.vikingcodeschool.com/posts/why-learning-to-code-is-so-damn-hard
Kuigi pisut ehk liialt kirjanduslik, tundub kodeerijate elu sarnane olevat piibellikule rännuteele - ei ole ju miskit uut Päikese all.
Kõigepealt Egiptuse meepotid.
Siis aga äkki tuleb ähmane äratundmine, et peab minema läbi mere, kuhugi kaugele ja proovida leida üles omaenese "Tõotatud maa". Kirjutama oma koodi, aitab teiste läbus sorimisest...
Rännakul kõrbes võib ette tulla igasugu asju, miraazhe, viirastusi, et nüüd on see tõotatu käes ja ometi on veel ees pikk tee.
Ja siis lõpuks, kui siiski, viirastub või saabub kusagilt toru lõpust valgus.
See kordub vähemal või suuremal määral mõne uue programmeerimiskeelega jälle, kuigi ehk veidi vähemal määral.
Meenub analoogia keeleõppega, kus väidetavasti iga uut keelt pidavat saama kiiremini õppida. Mina pole sellist asja väga märganud. Aga ega ma neid keeli ka väga palju ei oska - vene, saksa, inglise, prantsuse ja kõiki piisavalt halvasti, s.t. saab aru ja rääkida oskad 2 kõige rohkemini drillitut - jah, venet ja inglise oma ka natuke.
Nagu keeleõppelgi ei ole tegelikult õpikutest väga palju kasu, Ainuke viis õppida on kümmelda ja ise kirjutada ümber, jalgratast leiutades.
Vana "hea" C ei hiilga just kodeerijasõbralikkusega. Mühatab sulle korra "segmentation fault" teate ja sellega piirdubki. Kusagil on pang, aga otsi see ise üles.
Kõige sagedamini panen ma endiselt pange ikkagi mäluhaldusega.
Nüüd, natukenegi Javast kuulnuna tundub mulle viimane kaugelt vaadates lausa oaasina, puhkusena.
C-s tuleb kogu aeg eraldada kusagil mälu. Sa pead vaevlema sellega, et sama mälu jälle operatsioonisüsteemile tagasi anda, et see ei jääks programmile kasutult kätte. Sellist asja kutsutakse mälulekkeks ja tulemiks on programmi aeglane väljasuremine. Ühel hetkel vaba mälu enam ei ole, aga see hetk võib saabuda väga paljude töötundide järel. Programm paneb 2-l tööpäeval pange ja 1 päeval käib kui õlitatult....
Tore, oleme hoolikad ja vabastame mälu. Aga on veel toredam asi meie toredas C-s selle mäluga - ära vabasta üleliia. Kui juba vabastatud mälupesa minna veelkord vabastama, võib tulla ette 2 halba asja:
vähem halb on see, kui programm paneb kohe pange. See juhtub nimelt siis, kui programm pole jõudnud vabastatud mälupesa UUESTI kasutusele võtta. Siis C mäluvabastusfunktsioon "free" sülitab sulle sõbraliku ja lihtsa segmentation fault-i. Ära roni juba vaba pesa vabastama.
Kui aga see pesa ON kasutusse võetud uuesti, siis vabastad sa (tavaliselt mingi teegifunktsiooni) kasutuses oleva mälu, see võetakse mingi kolmanda asja poolt kasutusele, kirjutatakse uuesti üle ja nüüd jookseb programm kokku täiesti suvalisel ajal suvalises kohas. Tavaliselt siiski suhteliselt kiiresti, vahel koguni kogu aeg ühes ja samas kohas. Kohas, kus EI OLE VIGA.
Hõõrud silmi ja veendud veel ja veel: seal ei ole viga. Seda muuseas kahjuks juhtub ka piisavalt tihti, et seal ikkagi on viga, nii et tasub ka see koht ikka ja jälle põhjalikult üle uurida. Näide:
võrdusmärk on puudu või üle ("=" "==" asemel või vastupidi). 
Lõpuks jõuab ähmaselt kohale, et võiks ja peaks hakkama tegelema põhjalikumalt C keele putukatõrje vahendite, debuggeritega... ja nii edasi ja edasi ...
Mõnikord on aga jälle nii, et sama objekti mõnda osa ei olegi vaja vabastada, sest see mälueraldus on koodi sisse "raiutud" - see mälu eraldatakse programmile kompileerimise ajal. Mõnikord on jälle nii, et sama alamkoodi juppi kasutavad erinevad programmi osised - üks osis annab funktsioonile tööks üle objekti, kus see mälusosa on eraldatud dünaamiliselt, teine annab selleks üle konstandi, staatiliselt sisse raiutud objekti ja sellel pole võimalik vahet teha. Kolmas võimalus on selline, et see mälu vabastatakse automaatselt - funktsioon on lõpetanud tegevuse ja tema enda muutujaid hoitakse kohas, mida programmeerijad kutsuvad "pinuks". pinu saab vabaks ja ühekorraga toimetab teine funktsioon juba vabastatud mäluga.
Selline jahmerdamine toimub selle mäluga ja minu arvates on see üks suur tüütus ja ajaraisk. Aeg, mis võiks kuluda asjalikemate asjade peale, kulub ära mehhaanilise nikerdamise peale.
Teine sarnane hea asi, mis kõrvalt vaadates Javas on ja C-s ei ole, on try. Kui midagi läheb pange, siis Java SUHTELISELT automaatselt, eeldusel, et on kirjutatud midagi exception koha peale,  ronib programm veasituatsioonist välja, tehes ainuvõimaliku käigu - teatab sellest ja enamasti lõpetab. Kõik see asi aga on C kodeerija enda mure. Kuna absoluutselt iga asi, mida programm vajab operatsionoisüsteemilt, võib minna pange, tuleb iga operatsioonisüsteemi kallal käimise järel kontrollida, läks õnneks või ei läinud? See tähendab, et pooled koodiread on lihtsalt iff-id.
Tõenäoliselt on kõik ok selle mälueraldusega. Aga äkki ei ole, äkki kõik mälu sai mälulekke tõttu otsa. Sellest tuleks kusagil logis teada anda ja siis lõpetada, sest muidu võtab veaparandus otsatult kaua aega...
Nii on C programmid täis pikitud iff-sid.
Nüüd tulevad mängu uued tegelased - Security coding standardi meistrid. C -s ja mujalgi on nimelt selline häda: KÕIGE väiksem arv ja kõige suurem täisarv (näiteks nelja baidi korral) ei ole üksteise vastandid.
INT_MIN on -2147483648 ja INT_MAX is 2147483647.
Oletame nüüd, et sinu muutuja saab väärtuse INT_MIN. Teed selle muutujaga x = -x.
See muutuja EI OLE -x, ta on midagi, mida C keel ei defineeri. Äkki tuleb mingi viga. Äkki ei tule, x-i asemel on sel juhul mingi kahtlane väärtus, mis, seda keegi ei tea.
Et seda ei juhtuks, tuleks ohutu programmeerimise huvides alati enne x = -x i kontrollida, äkki x on vahepeal saanud väärtuse INT_MIN, nii igaks juhuks ...
Et selline kole asi on võimalik igal pool, kus tuleb graafikaga õiendada, sest seal on sageli vajalikud arvutused, siis võib ette kujutada, kui palju peaks "ohutu" koodi huvides selliseid imelikke kontrolle igale poole kirjutama. Kodeerija peab kinni lappima kasutatava programmeerimiskeele puudusi...
...
Kui viitsisite siiani lugeda, siis minge ja käige minu viidatud lingi ka ära. Minu arvates on seal päris hästi ära kirjeldatud, mis saabub kodeerijale pärast mesinädalaid. Kõrberännaku kestus võib olla erinev. Ealised iseärasused ei ole näiteks üldse soodustav faktor kõrbest väljumisel.Ja nii edasi ja edasi.
Ja mulle tundub, et ma ei ole siit veel saanud välja. Liiga palju aega virvendab minu ekraanil ja unenägudes kole "segmentation fault..."