2009-08-19 digital life Worte zur Portabilität So war es nicht gemeint Portabilität ist, meiner Meinung nach, eine wichtige Sache. Früher war es das noch viel mehr, vor allem im Bezug auf Hardware, heute wird es vor allem auf Betriebssysteme, und damit auf Software, bezogen. Doch wie sieht portable Software aus? Wenn man die Jungs der Bell Labs, die Schöpfer von Unix, fragen würde, so würde man lernen, dass Portabilität zwei Dinge bedeu- tet: Zum einen, Platform-spezifischen Code zu kapseln um diese Codesegmente auswechselbar zu machen. Und zum anderen, dass Portabilität direkt mit anderen Designzielen (Einfachkeit, Klarheit, Allgemeinheit) zusammenhängt. Portablen Code zu schreiben heißt guten Code zu schreiben. Guter Code ist einfach, klar, allgemein. Was Portabilität aber nicht primär heißt ist: Code der unverändert überall läuft. Es mag nett sein wenn das so ist, aber danach ist nicht zu streben. Das muss höchstens die Folge von obigen Zielen sein! Ich hatte mich mit Signalen unter Unix beschäftigt. Dabei heißt es immer wieder, dass dies und das in der `signal.h' definiert ist. Klar dieser Header ist die Signal-Schnittstelle für C- Programme -- also der zentrale Anlaufpunkt zu diesem Thema. Was liegt also näher (nachdem man das realisiert hat), als mal in die `signal.h' reinzuschauen um zu sehen wie eben diese Schnittstelle aussieht. Die zu kennen ist eigentlich schon der Erfolg, denn die Schnittstelle definiert die Funktionalität. Aber wenn man in die GNU-Implementierung der Datei dann rein- schaut, dann muss einen der Schlag treffen. (Wenn man nicht schon weiß was einen erwartet.) Den eigentlichen Inhalt der Datei muss man erst suchen. Das ist wie verrauschtes Radio. So sieht Portabilität heute aus. ... schrecklich! Es ist ein Schlag in den Bauch! So sollte Portabilität _nicht_ aussehen! Noch schlimmer ist die `assert.h'. Fünf Zeilen würden genügen, die GNU-Implementierung beinhaltet 55 (laut sloccount). Sie beinhaltet neun #if/#ifdef/ifndef wo eines genügen würde, die Verschachtelung ist drei Ebenen tief, und dann ist auch noch 'ne Abstraktionsebene eingezogen. Wozu das Ganze? Nur damit die Datei auf möglichst vielen Syste- men unverändert verwendet werden kann. Das mag für Enduser ja ganz nett sein, doch der Code ist dadurch einfach schrecklich. Nun ist die Frage, wie man dieses Problem löst. Wie sollte diese Datei aussehen? Ist sie womöglich schon in ihrer besten Form, da andernfalls der User sie für sein individuelles System anpassen müsste ... und hunderte andere Header und Makefiles ebenso? Ist es einfach die Folge der Unix-Zersplitterung mit der wir jetzt leben müssen? Doch 55 Zeilen statt fünf, das ist zehn mal mehr! Kann es sein, dass das nötig ist? Hätten irgendwelche Standards nur besser auf einander abgestimmt sein müssen? Hätten Systeme kompatibler designed werden müssen? Wäre die Situation dann heute besser? Mir tut es einfach weh wenn ich solchen Code sehen muss. Es muss doch auch besser gehen ... http://marmaro.de/apov/ markus schnalke