Diese Reihenfolge ist einerseits der Tatsache geschuldet, dass Pascal auf Single-Pass-Kompilierung ausgelegt ist (das heißt keine Nutzung darf vor der Deklaration erfolgen (mit wenigen Ausnahmen ala
forward
oder Pointer auf Records)), anderseits arbeiten "
Unit basierte" Compiler wie FPC und Delphi so, dass sie sich beim Kompilieren einer weiteren
Unit erst nur den Interface Teil der
Unit anschauen müssen, um festzustellen, ob sich was geändert hat und demnach die erste
Unit neukompiliert werden muss. Wenn du nun Teile des Implementationbereichs in den Interfacebereich schiebst, so muss der Compiler auch über diese Teile hinweg parsen, selbst wenn er sie eventuell gar nicht benötigt, weil sich nichts geändert hat.
Am Interface-Teil will ich ja an sich auch nichts ändern, sondern fände es schön, den implementation-Teil aufzusplitten in Deklarationen und die tatsächliche Implementierung. Und wenn der public-Teil am Anfang der
Unit steht, muss der Compiler ja auch über nichts überflüssiges hinwegparsen.
Wenn man sich aber deine Anmerkung bzgl. globalen Properties ansieht (welche, @restliche
DP in FPC übrigens verfügbar sind), dann müsste dort mindestens ein "private" Abschnitt vor einem "public" Abschnitt kommen und du hast den Salat wieder.
Zitat von
implementation:
Zitat:
Nichtsdestotrotz: Free Pascal unterstützt nicht-referenzgezählte Interfaces (so genannte CORBA Interfaces). Die kannst du (per
Unit oder eventuell sogar lokal per Deklaration, das weiß ich grade nicht) ganz einfach per "{$interfaces corba}" aktivieren.
Wenn dies tatsächlich per Deklaration geht, wäre das sehr praktisch. Dennoch fände ich es deutlich schöner, diese mit einem Schlüsselwort zu unterscheiden, da sie von ganz anderer Natur sind.
Ich hab mal schnell getestet: es ist wirklich eine lokale Option (wie {$M+/-}).
Zitat von
implementation:
Zitat:
Und es funktioniert auch wie es soll. "Free" ist nur eine normale Prozedur deren einziger Sinn es ist zu überprüfen, ob "Self <> Nil" ist und dann den Default-Destruktor "Destroy" aufruft. Nichts hält mich davon ab einen Destruktor mit einem anderen Namen zu definieren und einfach direkt aufzurufen. Es ist nämlich der Aufruf des Destruktors, der die Speicherfreigabe veranlasst, nicht der von Free (sonst bräuchten wir ja kein spezielles Keyword für den Destruktor).
Schöner wäre es aber, wenn der Destruktor das selbst überprüfen würde, dann bräuchten wir eben diese Methode Free nicht.
Es wäre interessant die Begründung von Borland zu hören, warum sie sich damals dafür entschieden haben, dass "Destroy" das nicht überprüft...
Zitat von
implementation:
Zitat:
Zitat von
himitsu:
- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)
Ich weiß nicht, ob das wirklich so gut wäre... es wäre schon schwierig sowas zu parsen:
Letztendlich wäre das ja nichts groß anderes, als die Schemata. Man müsste das nur syntaktisch ein bisschen austüfteln.
Die Einführung der Schemata wäre wahrscheinlich einfacher als sowas. "<" ist einfach zu sehr belastet...
Gruß,
Sven