JPL Institutional Coding Standard for C

ok csinaltak a Curiosity-t is

http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

( bervi | 2012. 08. 07., k – 19:23 )

Szép és jó, csak így mondjuk egy Firefox lefejlesztése 100 év lenne. Már ha C-t használnának. Nem véletlenül terjednek a menedzselt nyelvek...

Van Javahoz is draft ugyanott.

Bezzeg amikor meg Lispet hasznaltak a JPL-ben, nem kellett ilyen hatulgombolos szabalyrendszer...

Egyebkent a Firefox erosen nem "elet-halal kerdese" kategoria, ha egyszersketszer lefagy vagy elhasal, senki nem hal bele. Ezeket a szabalyrendszereket (mint ez vagy a MISRA, illetve Bjarne Stroustrup oldalan levo) ilyesmikre terveztek.

Igen, ráragasztották a vadászgép címkét, és? "SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAM"

Tudok mellé linkelni millió valós példát. De amúgy is, kit érdekel, hogy hol használják? A memóriavédelem nem csak itt érdekes, hanem mindenhol. Aki szerint csak kritikus rendszereknél érdekes a megfelelő erőforrás-kezelés, az inkább ne programozzon semmit.

A rendszerfejlesztes koltseget ezen a minosegen ki fogja megfizetni? Itt a code quality assurance rengeteg penzbe kerul. Mindenki ember, hibazik, nem minden szabalyt tud betartani, mert faradt/lusta/front van.
A jo minosegu szoftver fejlesztese NAGYON draga, lasd a peldat: http://www.fastcompany.com/28121/they-write-right-stuff
Space Shuttle szoftver, 17 hiba keletkezett a fejlesztes soran az utolso 11 verzioban. Nem, nem a teszteles soran jott elo ennyi, hanem 17 hibas kodot keszitettek a fejlesztok. 260-an dolgoznak a 420E soros kodon. Husz evre visszamenoleg megvan minden leirt kod forrasanak a dokumentacioja: ki, mikor, miert, milyen specifikacio alapjan es mit modositott.
35 millio dollarba kerul evente karbantartani a szoftvert.
Es itt nem csak memoriavedelemrol van szo. Egyaltalan nem. Hanem arrol, hogy maga a szoftverfejleszesi modszertan, a folyamat olyan, hogy nem enged sok hibat ejteni. Ha hiba kerul production kodba, ott nem csak a programozo a hibas, hanem az a folyamat, amelyik nem vette idoben eszre a hibat. Draga mulatsag ez, de lehet csinalni kozel hibamentes kodot.

És el is jutottunk oda, ahonnan indultam, hogy nem véletlenül terjednek a menedzselt nyelvek, mert azok rengeteg hibától óvnak meg. És nem kell rá évi 35 millió dollárt költeni. Meg kódsoronként meditálni rajta, hogy most vajon tényleg jó-e ez a kód, és ha nem, mi lesz vele. De az ilyeneket nem tudják felfogni a t. véglényekfelhasználók, mert nekik az a legnagyobb világfájdalmuk, hogy 20MB-tal többet eszik így a program.

Félreértés ne essék, én nem azt mondom, hogy a menedzselt nyelv varázsütésre megoldja a problémákat. Nyilván nem fogja. Én csak azt mondom, hogy nagyban megkönnyíti a folyamatot.

A menedzselt nyelvek nagyon sok mindent megoldanak, de mission critical helyen használhatatlanok, hiszen nem tudod érdemben befolyásolni a garbage collector lefutását. Külön szálon, valamikor a runtime által managelve fut. Ez egy mission critical környezetben elfogadhatatlan. A rendszer viselkedését meg kell tudni jósolni előre mindig.

Ha elolvasod a JPL coding standardet, ők is tiltják a dinamikus memóriahasználatot. Minden memóriaelemet inicializálni kell a taszk indításakor és az az egész taszk alatt úgy marad. A menedzselt nyelvek a dinamikus memóriahasználatból eredő problémákat (double free és társai) oldják meg. A JPL meg úgy oldja meg, hogy nincs dinamikus memóriahasználat. Főleg azért, mert kiszámíthatatlan a viselkedése, és a statikus kódelemzők sem tudják a kódot elemezni.

NPE, memory leak (azaz olyan objektum-foglalas, amit a GC nem tud feloldani, mert egy GC root meg mindig hivatkozik ra, pedig nem kene) igy is lesz. Csak kevesebbet kell gepelned, mert free-t nem kell meghivnod. heap allokalas ugyanugy van, csak new-nak hivjak.

Ez nem VM, hanem GC, es nem a GC problematikaja, hogy te a kodban mar nem foglalkozol az objektumoddal tobbet (soha nem fogsz a futas soran ra hivatkozni), de megis van olyan referencia ra (akar egy tipikusan szarul implementalt Singletonbol), ami miatt nem tudja felszabaditani az objektumot. Ez nem szar VM iras, hanem hanyag programozas. Pl. Javaban rendkivul kevesen ismerik, mi az a Weak/Soft/Phantom reference, pedig a hatekony memoriahasznalathoz elengedhetetlen. Es ez nem VM hiba, a VM adja a megfelelo memoriakezelo eszkozoket, de ha szarul hasznalod, akkor szar lesz.
Monduk hanyszor felejti el az ember mondjuk a Listenert levalasztani a megfigyelt objektumrol, ha mar nem kell neki? Rengetegszer. Hiaba nem kell mar a Listener altal megfigyelt objektum sehova, senki nem hasznalja mar, de mivel meg van ra strong reference, ezert nem fog tudni felszabadulni addig, amig a Listenerre hivatkozo osztaly (pl. inner classkent) nem mondja azt, hogy kosz, mar nem figyelem az objektumot.