012
19.07.2007, 23:47 Uhr
0xdeadbeef
Gott
(Operator)
|
Nicht nur. Es ist außerdem so, dass die Sprachstruktur es nicht sinnvoll anders erlaubt. Jedes Modul kennt nur das, was im entsprechenden Modul drin ist - die werden einzeln kompiliert. Bei Java zum Beispiel ist das nicht der Fall, der benutzt .class-Dateien wie Header. Außerdem sind Objekte in Java und C# immer Referenztypen, was wieder seine ganz eigenen Probleme mit sich bringt - zum Beispiel, dass Destruktoren nutzlos werden, weil du nicht weißt, wann sie ausgeführt werden (Liegt halt alles auf dem Heap), und generell werden Symbole da erst zur Laufzeit aufgelöst (Was widerum dazu führt, dass du sehr wenig zur Compilezeit abfangen kannst - siehe NoSuchMethodError).
Was das bedeutet ist, dass ein Java- bzw. C#-Compiler zur Laufzeit weniger wissen muss - der Klassenaufbau selbst ist zum Beispiel nicht notwendig, um einen Zeiger anzulegen, aber wenn du eine flache Instanz anlegen willst, wie in C++ üblich, musst du wissen, wie viel Speicher das Ding nachher belegt. Außerdem musst du den Aufbau kennen, weil die Symbole zur Compilezeit bereits aufgelöst werden. Die Namen der Membervariablen sind im Binärcode nachher nicht mehr enthalten und wurden durch offsets ersetzt, ähnliches gilt für die Auflösung der virtual function table etc. Und jetzt stell dir vor, Klasse A hat einen Member vom Typ B, und Klasse B hat eine Methode, die intern ein Objekt der Klasse A benutzt. Ohne Deklarationen kriegst du da ein Henne-Ei-Problem.
Außerdem, und deutlich wichtiger, hat die Aufspaltung in Module schon ihren Sinn - sie macht die Dinge übersichtlicher und den Code wiederverwendbarer. Stell dir vor, du willst Klasse C in zwei verschiedenen Projekten benutzen. Jedesmall kucken, wo du jetzt wie und unter welchen Umständen den Kram #includen kannst? Ich denke nicht.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra |
