list als rückgabewert einer dll klasse
-
Genau, ich würde ein stinknormales Array nehmen, welches innerhalb der dll erzeugt wird.
Dann würde ich noch eine Funktion bereitstellen die dieses Array auch wieder innerhalb der dll löscht.
-
Ah so.. Konnte mir schon irgendwie so was denken, aber wollte noch auf Nummer sicher gehen...
Okay, bevor ich es mit dem PODs probiere wollte ich es noch mit Pointern als Übergabeparamter probieren (sieht dann meiner Meinung nach besser aus, als wenn wieder extra Arrays existieren um die man sich kümmern muß)
Ich habe den Methodenaufruf erst mal so abgeändert:
void ConCore::getPluginList(list<string>* names) {D.h. er soll einen Pointer auf eine liste bekommen.
Der Aufruf sieht dann so aus
std::list<std::string> plugins; getCoreInstance()->getPluginList(&plugins);Sollte doch eigentlich klappen oder? Oder wird die Liste nur instanziiert?
Das Problem ist nämlich, das der Pointer nur quark liefert.Der Debugger sagt mir als value von names
names [3435973836](...)
Naja sieht nicht sehr überzeugend aus
Unterliegt das hier auftretende Problem, denn immer noch dem oben genannten Fehler oder einem Anderen?
Wenn ihr euch jetzt fragt: "Was macht der Kerl da eigentlich. Hat der denn überhaupt Ahnung vom Programmieren?" Dann möchte ich euch direkt sagen. Ich lerne gerade per Try and Error.... Und das in der Diplomarbeit. Leider sehr peinlich.
Edit: Nach weiterem Nachforchen bin ich erst mal soweit gekommen, dass der richtige Pointer an die Methode übergeben wird, also es wird die richtige Speicheradresse an die Methode übergeben.
Das Problem besteht vielleicht genau wieder da drin, was Maxi vorhin schon angesprochen hat. Innerhalb der DLL wird der Pointer an der Stelle nicht richtig Derreferenziert, wenn man auf ihn zugreift, also da:
names->push_back( Pluglist->next().name );Aber warum ist das so? Ich meine der Pointer bekommt doch durch deklaration mittels list<string>* genau gesagt welcher Typ er ist? Wieso derferenziert er sich nicht richtig? Oder ist die Art der Dereferenzierung (der Pfeil ->) nicht richtig?
-
Die Dereferenzierung ist schon richtig (zumindest theoretisch), aber die Speicherverwaltung vermutlich nicht.
-
Hmm, okay
Kann man denn feststellen, in welchen Bereichen die Applikation und die dll rumlungern? Sprich kann man irgendwie feststellen, ob die dll in den Speicherbereich der Applikation kommt und da auch auf die nötige Adresse zugreifen kann?
Meine gedanken dazu sind, dass die dll doch in den Speicherbereich der ladenden applikation eingeblendet wird. Ist das der Fall? Wenn ja, darf die dll auf den Speicherbereich der Applikation zugreifen, oder ist der geschützt?
Man das wird echt kompliziert.
Nochmal ein Edit:
Also wie ich mich gerade mal so versucht hab zu bilden ist mein Gedanke, dass die dll in den Speicherbereich eingeblendet wird, nicht korrekt.
Meiner Meinung nach gibt es jetzt nur noch 2 Möglichkeiten.
1. Ich schaffe es von der dll aus in den Speicherbereich der ladenden Applikation zuzgreifen, indem ich beim Laden der dll sage dass sie diesen Speicherbereich sehen und bearbeiten darf.
2. Ich beschränke mich wirklich auf primitive Typen, die ich dann halt umständlicher Bearbeiten muß.
Ich würde ja immer noch Möglichkeit 1 bevorzugen, aber wahrscheinlich wird das, wenn dann nur mit Instabilitäten gehen.
Naja erst mal drüber schlafen. Ihr könnt mir natürlich gerne noch weitere Tipps geben.
Grüße
Daimonion
-
daimonion schrieb:
dass die dll doch in den Speicherbereich der ladenden applikation eingeblendet wird. Ist das der Fall? Wenn ja, darf die dll auf den Speicherbereich der Applikation zugreifen, oder ist der geschützt?
ja sie darf zugreifen. das ist so als waere der code der dll in deiner software drinnen. du kannst anstatt einer dll auch eine lib verwenden und sie gleich statisch hinzufuegen. ist der gleiche kaffee.
Meep Meep
-
na das ist doch schon mal gut.
Jetzt gilt es nur noch herauszufinden, wieso ich in der dll den Pointer nicht richtig dereferenzieren kann.
Thema Speicherverwaltung, wie CStoll schon erwähnte. Berechnet die dll vielleicht die Offsetadresse falsch?
-
Äh.
Ich weiss nicht wieso immer wieder Leute Probleme mit DLLs und dem Heap haben.Verwendet einfach die DLL Version der Runtime Library, dann gibt es das Problem nicht. Wir verwenden haufenweise DLLs die Haufenweise STL Objekte (vector, string, ...) by-value hin und herreichen, Speicher wird da kreuz und quer angefordert und freigegeben - alles kein Problem.
-
Hallo und guten Morgen
Wie meinst du das die DLL der Runtime Library verwenden?
-
Mhhh, vielleicht liege ich damit falsch, aber als ich mal mit Interfaces* über DLL-Grenzen experimentiert hatte, habe ich den delete-Operator überschrieben, und auf Methoden in der DLL (die auch die Allozierung durchgeführt habe) zur Freigabe verwiesen. Vielleicht ist das ja noch ein weiterer Punkt...
* übrigens auch über Compilergrenzen. Nur kann dafür leider keine 100%ige Funktionsgarantie gegeben werden, unter den 2 Compilern die ich verwendet hatte, funktionierte es soweit getestet (Der eine war VC++ 6 der andere einer der auf einen Watcom Compiler aufgesetzt war).
cu André
-
Bei verschiedenen Compilern kann man zusätzlich noch das Problem unterschiedlicher STL-Implementationen haben. Ich hatte da schon Probleme bei einer dll aus dem BCB5 in einem Projekt aus dem BCB6.
Man könnte sicherlich auch die dll-Version der Runtime-Lib nehmen um das zu umschiffen. Das habe ich bisher aber noch nicht probiert da ich die Mitgabe vieler dlls vermeiden wollte. Ich werde das aber demnächst bei mir mal testen.
-
ne, ist beides nicht der Fall... Ich arbeite mit einem Compiler und habe bisher noch keinerlei Delete/new operatoren überschrieben.
Wie ist das denn mit den Runtime Libraries gemeint? Ist das eine Compileroption oder wie kann ich das verstehen? Also ich meine die Aussage von hustbaer.
-
Das ist eine Linkeroption. Man kann die Runtimelib statisch dazulinken oder als dll mitgeben. Wenn du sie als dll mitgibst mußt du halt darauf achten, dass diese dll bei den Sytemen vorhanden ist auf denen du dein Programm einsatzen willst.
-
Braunstein schrieb:
Das ist eine Linkeroption. Man kann die Runtimelib statisch dazulinken oder als dll mitgeben. Wenn du sie als dll mitgibst mußt du halt darauf achten, dass diese dll bei den Sytemen vorhanden ist auf denen du dein Programm einsatzen willst.
Das ist mir klar, dass die DLL auf den Systemen dann vorhanden sein muß, wenn ich die bibliothek als DLL compiliere. Wenn ich sie als Lib compiliere und statisch dazulinke, bedeutet das doch, dass ich diese ganze loadlibrary geschichte abhacken kann? Außerdem ist meine bibliothek als lib compiliert, um ein vielfaches größer.
Irgendwie kann ich mir nicht vorstellen, das Hustbaer das gemeint hat.
-
Ich denke schon das er das gemeint hat. Es gibt dann nämlich nur eine Runtimedll für deine Dll und für dein Hauptprogramm.
-
Ja, aber ich kann nicht statisch linken. Ich bin auf dynamic linking angewiesen, da ich eine variable anzahl an Bibliotheken habe.
-
Erstens sollst du ja gerade dynamisch linken und zweitens kannst du doch für jede Bibliothek separat entscheiden ob du statisch oder dynamisch arbeiten willst.
-
Braunstein schrieb:
Erstens sollst du ja gerade dynamisch linken und zweitens kannst du doch für jede Bibliothek separat entscheiden ob du statisch oder dynamisch arbeiten willst.
Naja so einfach ist das nicht, da die Bibliotheken dann später variabel dazukommen, aber irgendwie hab ich jetzt völlig den Überblick verloren.
Wie kann ich denn eine dll erstellen und dabei auf statische bindung setzen?
Beim erstellen meiner DLL wird ebenso eine lib erstellt. Die wird auch von mir in mein Programm eingebunden. Ist das schon das, wovon wir die ganze Zeit reden?Wenn nicht, könnt ihr mir nochmal erklären wie ihr das alles meint?
-
Genau, das ist statische Bindung. Was wir meinten ist aber noch etwas anderes. Statt einer dll kanst du auch eine lib verwenden in der alles drin ist was du brauchst. Bei der Runtimedll würde das bedeuten, dass du alle Funktionen asu der RTL die du brauchst mit in dein Programm gelinkt werden und dann keine dll gebraucht wird.
-
Ich meine dass man die C++ Runtime Library wo "new" und "delete" und 100 andere Sachen implementiert sind als DLL linken soll. Damit gibt es nurmehr eine Version von "new" und "delete" die alle verwenden, und nurmehr einen Heap, und eben kein Problem mehr.
Beim MSVC nennt sich das "Runtime Library: Multi-threaded DLL" oder auch "/MD".Klar muss auch überall der selbe Compiler und die selbe STL verwendet werden, bloss das ist auch nicht anders wenn man LIBs verwendet.
-
Hallo hustbaer.
Danke für den konkreten Hinweis auf die Einstellung.
"Multi-threaded DLL" war bei mir schon eingestellt, aber halt nur "Multi-threaded DLL". In meiner Hauptapplikation war "Multi-threaded DLL Debug" eingestellt (was ja auch richtig ist wenn das Projekt als Debug eingestellt ist) und dieser Unterschied verursacht den Derferenzierungsfehler.Nachdem ich in allen Projekten diese Option einheitlich auf "Multi-threaded DLL Debug" eingestellt hatte, funktioniert auch mein Code.
Danke an alle für die Tipps.
Grüße
Daimonion
