Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (WinAPI, Konsole) » Funktionsaufruf in DLL, kopieren von Variablen und Absturz

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
07.06.2006, 17:25 Uhr
stephanw
localhorst


Hi,

vorab: ich habe gesucht, sowohl hier im Forum als auch in der MSDN. Folgendes Problem:

Ich habe ein Programm, das eine DLL linkt, in der ein paar Klassen enthalten sind. U.a. ein Werkzeug zum Parsen von Kommandozeilen-argumenten. Dann sinngemäß folgender Code:


C++:
// in der DLL
class CommandLineTool
{
public:
  // ...
  bool getValue( const char* option, std::string & value ) const;
};

// im Programm

int main(int argc, char** argv)
{
  CommandLineTool commandLineTool( argc, argv );

  std::string filename;

  if (commandLineTool->getValue( "-f", filename))
  {
    // es wurde ein Dateiname übergeben
  }
}



Die Funktion getValue() kopiert dann in den per Referenz übergebenen String. Mir geht es genau um dieses Kopieren. Dieses Beispiel ist nur eines, ich hatte schon zig Beispiele, wo (vorzugsweise mit std-Template-Klassen) das Kopieren per Zuweisung, Copy-Konstruktor o.ä. "über DLL-Grenzen" unter Windows fehlschlägt. Kompiliert man mit MS-VC mit der Einstellung "Multi-Threaded-DLL" o.ä., geht alles gut. Wenn nicht, kommt im Debug-Mode ein "BlockValid" assert oder so ähnlich, habs grad nicht vor mir ;-) Jetzt möchte ich aber mit Cygwin/MinGW g++ kompilieren, dort wüsste ich jetzt kein entsprechendes Flag :-(

Fehler in der Implementierung kann ich ausschließen, es beschränkt sich auf das Kopier-Problem. Beim Kumpel mit Linux/MacOSX klappt das wohl ohne Probleme. DLL und EXE sind jeweils mit demselben Compiler übersetzt.

Meine Frage: ist das ein Problem, was entsteht, weil durch Template/Inline-Generierung potentiell verschiedener Code entsteht, der dann vielleicht nicht zusammenpasst oder ist das ein Problem der Speicher-Verwaltung unter Windows ?

Hat jemand eine Idee, wie ich das mit dem g++ fehlerfrei hinbekomme ?

Ich möchte es möglichst vermeiden, in den DLL-Schnittstellen nur eingebaute Datentypen wie int, float, char* etc. zu benutzen, std-container und strings hätte ich eben gerne.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
08.06.2006, 14:51 Uhr
Th



Wichtig ist dann vorallendingen, daß sowohl die DLL als auch das Hauptprogramm mit derselben Runtime-Lib gelinkt sind, ansonsten bumm...

d.h. wenn du dein Programm im Debug-Modus laufen läßt, muß es auch die Debug-DLL benutzen und im Release-Mode eben die Release-DLL.

Außerdem funktioniert dies natürlich immer nur, wenn du den selben Compiler für beide (DLL + Programm) benutzt (wegen C++ Schnittstelle, anstatt einfacher C-Schnittstelle).

Ansonsten würde ich dir empfehlen, die DLL statisch zu linken.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
08.06.2006, 18:52 Uhr
stephanw
localhorst


Könntest Du das nochmal genauer erklären mit der Runtime-Lib ?

Also nochmal kurz:
Ich erstelle DLL und EXE jeweils mit denselben Compiler-Einstellungen bzgl. Optimierung etc. und Debug/Release. Beim MSVC musste ich dann immer diese Multi-Threaded-DLL Variante einstellen, damit es nicht crasht. Beim Cygwin/MinGW-g++ gibts sowas nicht, und hier crasht es dummerweise. Wie gesagt, beide Programmteile sind dann mit g++ und gleichen Optionen übersetzt.
Gelinkt wird im Fall von MSVC mit einer Lib zur DLL und im g++-Fall nur die DLL mit z.B."-ltools", da gibts dann keine Lib bzw. kein *.a-File.
--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 08.06.2006 um 18:53 Uhr von stephanw editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
08.06.2006, 22:50 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat von Th:
Wichtig ist dann vorallendingen, daß sowohl die DLL als auch das Hauptprogramm mit derselben Runtime-Lib gelinkt sind, ansonsten bumm...

d.h. wenn du dein Programm im Debug-Modus laufen läßt, muß es auch die Debug-DLL benutzen und im Release-Mode eben die Release-DLL.


sorry aber das ist Unsinn. Wenn du ein Programm im Debug Modus laufen lässt werden zig anderen Dlls geladen deren Debuginformationen nicht bekannt sind.
Genauso kannst du auch nur deine Dll debuggen die aus einem Programm aufgerufen wird welches nur als Release Version vorliegt.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
10.06.2006, 10:16 Uhr
xenayoo



Es mag sein, dass ich jetzt falsch liege, abe nach meinen Erfahrungen sieht die Sache so aus: Normalerweise können nicht einfach mehrere Programme die Werte in einer dll miteinander teilen. Das bedeutet, dass versiedene Programme zwar die selbe dll verwenden können, aber jedes eben nur mit eigenene Werten - damit kein Datensalat entsteht.
Nun gibt es zwei Möglichkeiten, um dieses zu umgehen, wenn man es nun unbedingt will: entweder definiert man für ausgewählte Container ein shared Datasegment oder sorgt dafür dass sich die dll eben anders verhält ("Multi-Threaded-DLL" ). Dies findest du aber normalerweise sehr wohl dokumentiert im MSDN.
Grund des Problems: Windows ist nun mal nur ein Pseudo-Multitasking-System während Linux/MacOSX ein echtes BSD-Unix-System ist. Genau das macht den kleinen Unterschied aus. Im Endeffekt muß man wohl den Code für die beiden verschiedenen Systeme anpassen und via #if -Präprozessordirektiven beim Kompilieren unterscheiden....
--
Wer Rechtschreibfehler findet, darf sie behalten.... ;)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
13.06.2006, 12:24 Uhr
stephanw
localhorst


@xenayoo:

Ich will kein shared-memory, ich will es genauso, wie es normalerweise ist: Jedes Programm lädt seine Instanz der DLL. Und das Problem tritt auf, wenn beides (DLL & EXE) mit z.B. Cygwin compiliert wurden.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (WinAPI, Konsole) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: