Hi,

hab schon hier auf der seite und bei google nach gesucht, wie man denn funktionen einer klasse exportieren kann.
hab nix gefunden
gibts da ne möglichkeit oder muss ich mich etwa von den klassen verabschieden?

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Was verstehst du darunter?

Klassen können sehr wohl Exportiert werden. Wenn du jedoch C/C++ compatible Klassen erstellen möchtest musst du auf Interfaces zurückgreifen. Ich habe zwar noch nie eine Klasse exporiert, es dürfte allerdings kein Problem darstellen.

Wenn allerdings die Funktion nichts mit der Klasse zu tun hat, dann hat sie bei der Klasse auch nichts verloren.


MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

hab folgende drei möglichkeiten ausprobiert:

exportiert werden soll die Funktion GetWind(...) im Objekt TParticleEffectContainer:

Methode 1:

exports TParticleEffectContainer.GetWind; <=== Fehler: E2276 Bezeichner 'TParticleEffectContainer' kann nicht exportiert werden

Methode 2:

exports TParticleEffectContainer; <=== Fehler: E2276 Bezeichner 'TParticleEffectContainer' kann nicht exportiert werden

Methode 3:

exports GetWind; <=== Fehler: E2003 Undefinierter Bezeichner 'GetWind'


Funktionen/Prozeduren außerhalb von Klassen lassen sich einwandfrei exportieren

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Bei Klassen muss anders vorgegangen werden. Am besten du nutzt Interface[s] um das ganze Sprachunabhängig zu halten.

Schau dir mal die Benchmark Version von Lars an,
viewtopic.php?p=31414#31414
da hat er das schon gemacht.

Natürlich steht auch was in der Delphi-Hilfe etwas zu Interfaces drinnen.
Und wenn du selber mal Interfaces von andern nutzen möchtest, kannnst du die Typbiblothek import Funktion von Delphi nutzen.

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

sorry wenn ich mich so dumm anstell, aba ich blick da einfach nicht richtig durch

1. bzgl. DLLs hab ich 3 einträge in der hilfe, ein keinem steht was von interfaces (Delphi 2005 PE)
2. ich versteh nicht ganz wie man hinterher die Klasse einbindet (is soweit ich das gesehn hab nirgendwo im benchmark geschehn (hab nach 'module1.dll' un 'TModule1' durchsucht))

also kannste das nomma für ganz dumme erklärn?

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Ich habe nicht die Klasse exportiert, sondern nur die Schnittstelle. Das hat den Vorteil, dass es sprachunabhängig ist, und das Hauptprogramm und die DLL nur die Schnittstellendefinition einbinden müssen und nicht die ganze Klasse. Man kann also die tatsächlichen Klassen beliebig ändern, solange sie nur diese Schnittstelle implementieren und ist dadurch sehr flexibel. Beim Benchmark ist die einzige gemeinsam genutzter Datei addon.pas mit den Interface Definitionen.
Da Interface jedoch keinen constructor haben können, muß man eine Funktion in der DLL
exportieren die diese Aufgabe übernimmt.
Beim Benchmark können in einer DLL mehrere Module sein, deshalb wird noch ein Index übergeben.




Unter .Net ist das alles aber wesentlich einfacher. Da braucht man sich um solche Sachen nicht mehr zu kümmern. Man fügt einfach die DLL als Referenz zum Projekt hinzu und kann automatisch alle Units aus der DLL nutzen wie als wären sie im eigenen Programm.

Das Problem ist, dass Klassen eine Sache des Compilers sind (zummindest früher, wies jetzt bei .NET ist weiß ich nicht). Bei C++ sehen die Klassen anders aus als bei Delphi (Nicht nur vom Quelltext her, sondern auch im Speicher). Da kann sich z.B. die Virtuelle-Methodentabelle unterscheiden, die Callingconventions sind sowieso anders, ...
Was natürlich funktioniert, ist einfach die Klasse von einer Basisklasse (die als eine Unit dem Prog zur Verfügung steht) ableiten, und aus der DLL einen Pointer rausreichen. Aber wirklich sauber und elegant ist das nicht. Denn dann kannste die DLL auch nur mit Delphi machen (also nicht mit C++) und musst bei Delphi auch noch hoffen, dass die in ner neueren Version die Klassen nicht geändert haben.

Das ist so nicht ganz richtig. Stdcall ist in C++ und in Delphi stdcall. Das darf gar nicht anders sein, da man aus Delphi sonst keine Methode einer C++ Dll aufrufen könnte. Und das wäre schlichtweg fatal für unseren Berufsstand. Die VFT ist abhängig von der definition der Klasse. Wenn eine C++ Klasse und eine Delphiklasse 100%tig genau gleich definiert wurden ist die VFT auch gleich und man könnte eine C++ Klasse aus einer Dll erstellt in Delphi benutzen. Allerdings bekommt man Fehler nur mit, wenn es eine Access Violations gegeben hat. Und dann muss man raten wo sich das Problem befindet. Gehen tut es aber ich kann nur davon abraten. Ich habe so etwas leider schon mal machen müssen.

Ich würde entweder auch zu interfaces raten oder das so aufziehen wie es in OpenGL der Fall ist. Also Methodenbasiert. Eine zum Erstellen der Klasse. Eine zum Löschen der Klasse. Und dann die die du brauchst. Jeweils mit ID übergeben. Das würde ich auch empfehlen, wenn dir Interfaces zu viel sind. Die sind nämlich nicht unbedingt etwas für unerfahrenere Entwickler.

Ja, aber C und Delphi nutzen nicht standardmäßig StdCall, oder? Doch nur wenn manns ihnen sagt.

Das die Methodentabelle (und der ganze andere Kram) bei C++ und Delphi gleich ist, wusste ich nicht. Gehöre aber auch noch zu den Turbo Pascalern die die alten Object Dinger benutzen und da isses ganz bestimmt nicht wie in C++ (habs nie ausprobiert, kanns mir aber nicht vorstellen).

Hast aber recht, dass es wie gesagt nicht die sauberste Lösung ist. Kommt also drauf an, was es werden soll. So wie ich das sehe, geht die Methode noch am schnellsten. Bei größeren und komplizierteren Sachen, würde ich natürlich auch davon abraten.

Japp. Delphi benutzt von hause aus Register als Konvention. Da versucht er nach Möglichkeit alles über die register zu handeln. Denke mal C / C++ wird das nicht anders machen.


Wenn die DLL auch ausschließlich nur im eigenen Programm verwendet werden soll, dann kann man das natürlich so machen. Oder eben Instanzen der Klassen zurückliefern. Aber dann hat man das Problem, dass man diese ausschließlich nur im eigenen Programm verwenden kann. Und wer weiß schon so genau was da noch alles hinten dran hängt.

PS: Das Doppelpost habe ich gerade mal gelöscht.

hab jetzt wirklich nochma versucht, den ganzen benchmark zu durchschauen.

um das ganze nicht zusammenhangslos zu gestalten, hab ich auch ma diese funktion zurückverfolgt:



das Interface IBenchmarkmodule ist in addon.pas definiert, schön und gut.
von da an gehts für mich nichtmehr weiter.
den einzigen kontakt mit einer DLL hab ich in modulelist.pas gefunden, wo nur zwei exportierte funktionen geholt werden.
also wo sind die funktionen etc. für die Interfaces definiert?
sorry aber ich kenn mich in punkto interfaces/dlls wirklich kein bisschen aus und der benchmark ist wirklich zu komplex für mich

ich hab mal ne bitte an euch:
kann mir irgendjemand eine einfachste libary schreiben, die eine klasse mit einer funktion und vielleicht ein paar variablen exportiert (zum beispiel zwei zahlen addieren) un diese libary dann auch in nem beispielprogramm benutzen?
DANKE

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Das ist richtig. Die DLL exportiert nur die beiden Funktionen um für das Hauptprogram ein Objekt zu erstellen, dass das Interface implementiert.

IBenchmark gehört zum Hauptprogramm und wird von TBenchmark in der unit benchmark.pas implementiert.
IBenchmarkModule wird von TBaseModule in der unit module.pas implementiert und enthält eine Standardimplementation von IBenchmarkModule, damit man nicht alle Funktionen für jedes Modul neu implementieren muß.

Das Hauptprogramm spricht die einzelnen Module als IBenchmarkModule an und jeder Benchmark kann Funktionen aus dem Hauptprogramm über die IBenchmark Schnittstelle aufrufen.

Daher ist das ganze recht flexibel und die Klassen auf beiden Seiten können sich ändern, solange sie nur jeweils das Interface implementieren und jede DLL muß natürlich GetModuleCount und CreateModule exportieren.
Man könnte den Benchmark als völlig andere Anwendung z.B. in C++ und MFC programmieren und die bisherigen Module würden nichts davon mitbekommen. Bei den Interface geht es nicht um Vererbung, sondern nur darum festzuhalten, dass bestimmte Methoden auf jeden Fall in der Klasse vorhanden sind.

ok danke, aber ganz durchgeblickt hab ich immernoch net - durch die ganzen einzelnen units ist mir das ganze einfach viel zu komplex...
ich bitte aber darum mir jetzt nicht gleich zu sagen, dass ich das ganze jetzt schmeißen soll. zwar programmiere ich auch schon etwas länger, aber mit dem thema hab ich mich noch nicht beschäftigt und es hat schließlich jeder mal damit angefangen. wäre euch deswegen für ein sehr einfach gehaltenes beispielprogramm und vielleicht noch einem tutorial (wenn jemand eins kennt) das die interfaces erklärt SEHR DANKBAR

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)