En Javaprogrammerare gör ett återbesök i C land
- mån 1 dec, 2008 kl 23:35
- 8 kommentarer
- Java
Det var ett par år sedan jag körde C riktigt ordentligt och för några dagar sedan blev jag lite sugen när jag skrev ett litet multitrådat c program för att testa hur snabbt man kan göra vissa beräkningar på en multicore maskin.
C är ju ett mycket enkelt språk och faktiskt rätt lätt att lära sig eftersom det inte finns så mycket man kan göra i själva språket. Men efter många år av programmerande i den objektorienterade världen vill man ju gärna inte sluta programera objektorienterat, då det är ett bra sätt att bygga sina program eftersom det mappar rätt bra mot verkligheten. Att programmera objektorienterat i C går bra faktiskt även om det inte finns stöd för det i själva språket. Exempel på objektorienterad C kan man se i GTK+ och GNOME. Att däremot skapa egna klasser och hantera arv och dyligt i objektorienterad C är ett rent h***te.
Mitt val blir istället en kompromiss där jag kör med structar som representerar klassen på ett objekt och sedan metoder som manipulerar detta objekt. Alla metoder tar in en pekare till objektet som första parameter precis som medlems metoder i Python. Koden blir helt ok och det går att skriva väldigt tydlig och läsbar kod.
Som van objektorienterad programerare så börjar jag med att skapa min ”klass” och dess metoder. Allt flyter på fint och jag skapar konstruktorer och destruktorer. Men eftersom det är en applikation som skall jobba som en server blir det ju väldigt mycket saker som kan gå fel rent IO mässigt och då måste man ju kunna returnera fel till de anropande metoderna.
Här börjar problemen. Man kan ju välja olika felrapporterings tekniker som tex returnera en status kod eller skicka med en pekare till en fel struktur. Hur som helst så är detta relativt problemfritt att lösa i själva metoden men det är koden som tar emot felen som blir helt kalasdålig. Jag vet ju att detta har varit problem förut men jag har helt förträngt hur oändligt dåligt det är med felhanteringen i C. Det går ju inte heller att kompromissa bort felhanteringen och eftersom det är ett språk baserat på pekare till minnesareor så är det ju desto viktigare att man har ordentlig felhantering.
Jag läste på något forum att c1x (nästa c standard) kanske skall innehålla nån ny felhanteringsteknik liknande try catch som finns i så många andra språk. Av mina erfarenheter med C så tycker jag att om de bara kan fixa en enda sak så borde det vara ordentlig felhantering. Jag kommer nog inte att fortsätta att bygga min applikation i C på grund av att jag min högsta prio är ren, tydlig och vacker kod och det kan jag inte få om det är en klase felhantering under varje metodanrop. Det kanske är dags att testa nästa språk i alfabetet D. ;-)
Här är budord nr 6 av ”The Ten Commandments for C Programmers”:
”If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ”it cannot happen to me”, the gods shall surely punish thee for thy arrogance.”
Nu tycker jag du är kinkig, C är ett underbart språk.
Första stycket gjorde mig intresserad av att läsa vidare i inlägget. Dock var resten helt avstyckat från inledning, trist.
@roger: Det var kanske int helt tydligt vad syftet var.. Jag hade hellre skrivit om detaljerna hur jag programerade trådat i c för att testa prestanda men eftersom detta är en Java sida så valde jag att skriva om hur jag som Java programmerare upplevde det att programmera i C igen. Men jag förstår att du blev besviken.
@tomas: Jodå C är allt ett fint språk men jag tror inte att det finns nått språk som inte måste updateras. Jag har läst rykten om att det kanske kan komma in closures i C och jag hoppas verkligen att dom först satsar på att lösa såna här saker som felhantering. Det finns verkligen inget bra sätt att lösa det på. Kollar man tex på glib (gtk) och ser hur dom har löst det så är det ändå ett hack för att lösa en uppenbar brist i språket. Man klarar sig fint utan klasser,polymorfism osv men ordentlig felhantering är något som borde införas.
Void-pekare är allt som behövs sen är allt möjligt :-)
Precis!
Skillnaden mellan closures och void* är lite syntaktiskt socker. Skicka en funktionspekare och du är hemma!
Jag håller med om att undantagshanteringen behöver fixas till. Om något ska införas i C, så är det det.
C är väldigt maskinnära. Det är lätt att se hur features i C motsvarar features i assembler. Men även på maskinnivå finns undantagen. Därför är det märkligt att inte språket haft specialhantering av undantag redan tidigare.
Hej Per!
Intressant läsning, fast jag är rätt nöjd över att inte behöva knacka C till vardags. Men jag blev också nyfiken på flertrådningsaspekten från ingressen.
Själv är jag fast i GWT/Seam-träsket. Hoppas allt är gött i övrigt!
/Din gamla Siemenskollega
Hade du valt att köra C++ så har du tillgång till try catch block. Har funnits sedan 90 talet.
Skall också ge mig på det här någon dag. Var några år sedan nu.