Eigene Basisklassen definieren

[Der Jan]

Hallo zusammen,

in Delphi wird eine Klasse, in deren Definition nicht explizit eine Basisklasse angegeben wird, von TObject abgeleitet. Gibt es eine Möglichkeit, das irgendwie zu umgehen, sprich eigene Basisklassen zu definieren, wie z.B. in C++ ?

[mkinzler]

Nein. Jede Klasse erbt von TObject.

[Der Jan]

Hm, das könnte man ja fast als Antipattern bezeichnen
Zumindest schränk es die Kompatibilität von Delphi/OP mit Bibliothen anderer Sprachen extrem ein.

Ich hab auf diesem Rechner kein Delphi, drum kann ich nicht die OH quälen, aber AFAIK definiert TObject doch schon einige Methoden, oder ist sie rein virtuell?

[mkinzler]

Ist in Java, C# (alle .Net Sprachen) genauso und ich würde das eher als Feature bezeichnen. Inwiefern schränkt das dich ein?

[Der Jan]

Hintergrund des ganzen ist, dass ich gerade die Möglichkeit prüfe, eine C++ Klassenbibliothek in Delphi nutzbar zu machen. Diese definiert aber quasi "vom Urschleim" her alle verwendeten Typen als Klassen. Wenn diese jetzt in Delphi von Tobject abgeleitet sind, kriegt man den ganzen Spaß nimmer kompatibel.

[mkinzler]

Das bekommst du auch so nicht. Unabhängig von den Attributen und Methoden die die Klasse in Delphi von TObject erbt

[Apollonius]

Wieso hast du ein Kompatibilitätsproblem? Der erste selbstnutzbare VMT-Offset ist auch in Delphi Null.

[DMW]

Zitat von Der Jan:

Hintergrund des ganzen ist, dass ich gerade die Möglichkeit prüfe, eine C++ Klassenbibliothek in Delphi nutzbar zu machen. Diese definiert aber quasi "vom Urschleim" her alle verwendeten Typen als Klassen. Wenn diese jetzt in Delphi von Tobject abgeleitet sind, kriegt man den ganzen Spaß nimmer kompatibel.

Du könntest zur Not so etwas wie das hier versuchen.

Für den Produktiveinsatz muß ich allerdings dringend abraten: jede auch nur implizite Behandlung solcher Pseudoklassen als Delphi-Klassen (anders gesagt, jeder Zugriff auf negative Offsets der gar nicht vorhandenen Delphi-VMT) führt mit etwas Glück nur zu einer AV, ansonsten zu Speicherkorruption. Und wenn eine Exception in C++-Code geworfen wird, kann sie in Delphi nur mit einem allgemeinen try/except-Handler als externe Exception (falls du C++Builder verwendest, wäre es der berüchtigte Exception-Code EEFFACE) gefangen werden, und ebenso umgekehrt.

Der sauberste Weg wäre vermutlich, ein paar Wrapper-Interfaces zu definieren und die C++-Klassen davon ableiten zu lassen. Auf der C++-Seite mußt du dich dann aber manuell um das Abfangen von Exceptions in Interface-Funktionen kümmern; in Delphi gibt es dafür safecall.

[Der Jan]

Erstmal danke für die Antworten.

@DMW: Das Flatting kenn ich. Das kommt aber hier nicht in Frage, ebenso wie die Wrapper-Interfaces, denn es handelt sich um mehrere hundert Klassen. Der (gepackte) Sourcecode ist ca. 100 MByte groß

Also sieht es wohl so aus, als werde ich das Projekt begraben, bevor es geboren wurde. Zumindest vorerst

[DMW]

Zitat von Der Jan:

@DMW: Das Flatting kenn ich. Das kommt aber hier nicht in Frage, ebenso wie die Wrapper-Interfaces, denn es handelt sich um mehrere hundert Klassen. Der (gepackte) Sourcecode ist ca. 100 MByte groß

Also sieht es wohl so aus, als werde ich das Projekt begraben, bevor es geboren wurde. Zumindest vorerst

Wenn es dir vordergründig darum geht, die Bibliothek in Delphi nutzbar zu machen, ist es wohl aussichtslos. Falls du aber ein konkretes Projekt damit umsetzen möchtest und gerne Delphi und VCL fürs Frontend verwendet hättest, dann ist C++Builder das Werkzeug deiner Wahl: dort kannst du Delphi- und C++-Units nach Belieben kombinieren.
Die Teile des Programmes, die VCL-Frontend und C++-Backend verbinden, müßtest du allerdings in C++ schreiben.