C++ Übergeben std::string durch den Verweis auf die Funktion in der dll

Habe ich das problem mit der übergabe by reference std::string Funktion in der dll.

Diese Funktion aufrufen:

CAFC AFCArchive;

std::string sSSS = std::string("data\\gtasa.afc");

AFCER_PRINT_RET(AFCArchive.OpenArchive(sSSS.c_str()));
//AFCER_PRINT_RET(AFCArchive.OpenArchive(sSSS));
//AFCER_PRINT_RET(AFCArchive.OpenArchive("data\\gtasa.afc"));

Diese Funktion header:

#define AFCLIBDLL_API __declspec(dllimport) 
AFCLIBDLL_API EAFCErrors CAFC::OpenArchive(std::string const &_sFileName);

Ich versuche zu Debuggen, pass-by-step durch die Funktion aufrufen und schauen _sFileName Wert innerhalb der Funktion.

_sFileName in Funktion setzt einen beliebigen Wert(beispielsweise t4gs..\n\t).

Ich versuche zu erkennen, keine heap-Beschädigung, aber der compiler sagt, dass es kein Fehler ist.

DLL kompiliert wurde, die im debug-Einstellungen. .exe-programm kompiliert in debug zu.

Was ist falsch?? Hilfe..!

P. S. ich habe Visual Studio 2013. WinApp.

BEARBEITEN

Habe ich header ändern der func diesem code:

AFCLIBDLL_API EAFCErrors CAFC::CreateArchive(char const *const _pArchiveName)
{
    std::string _sArchiveName(_pArchiveName);
    ...

Ich weiß wirklich nicht, wie man diesen Fehler beheben kann...

Über den Haufen: Sie zugeordnet sind, im virtuellen Speicher unseres Prozesses, richtig? In diesem Fall, gemeinsam genutzten virtuellen Speicher üblich ist.

  • Wurden die EXE-und DLL kompiliert mit genau dem gleichen compiler, exakt die gleichen flags? Ansonsten werden die Definitionen der std::string und andere STL-Typen sein könnte, der Unterschied zwischen der EXE und der DLL, und die, die Probleme verursachen können.
  • Ich würde empfehlen, dass Sie halten Sie Ihre DLLs mit einem gut definierten ABI . Vorbei zugewiesenen Speicher über eine DLL-Schnittstelle ist nach ärger. Die DLL und das aufrufende Anwendung möglicherweise nicht mit den gleichen heap, zum Beispiel.
  • warum sollte das ein problem sein, wenn Sie nicht verwenden Sie die gleichen heap? Sie immer noch teilen sich den gleichen Adressraum, richtig?
  • Gut, wenn er hinzu fügt, um die Zeichenfolge und es befreit Speicher und reserviert neuen Speicher, der andere Haufen wird nicht frei, weil Sie es nicht kennen, block, etc.
  • basic_string(const _Elem *_Ptr) - es hieß nach .c_str(). _Ptr bei der Eingabe in der Funktion ist richtig: "Daten\\gtasa.afc"
InformationsquelleAutor Aleksey | 2014-03-09
  1. 7

    Das Problem hat wenig zu tun mit STL, und alles zu tun, übergeben von Objekten über die Anwendung hinweg.

    1) die DLL und Die EXE-Datei muss kompiliert werden, mit der gleichen Projekt-Einstellungen. Sie müssen dies tun, so dass die Struktur, Ausrichtung und Verpackung sind die gleichen, die Mitglieder und member-Funktionen nicht anders Verhalten, und noch mehr subtile, low-level-Implementierung eines Referenz-und Referenz-Parameter ist genau das gleiche.

    2) Die DLL und die EXE-Datei muss die gleiche Laufzeit-heap. Um dies zu tun, müssen Sie die DLL-version der Laufzeit-Bibliothek.

    Würden Sie festgestellt haben das gleiche problem, wenn Sie eine Klasse angelegt, die macht ähnliches (in Bezug auf Speicher-management) als std::string.

    Wohl der Grund für die Beschädigung des Speichers ist, dass das Objekt in Frage (std::string) ordnet und verwaltet dynamisch zugewiesenen Speicher. Wenn die app verwendet einen heap, und die DLL mit einem anderen Haufen, wie soll das gehen, wenn Sie instanziiert die std::string in sagen wir, die DLL, sondern die Anwendung ist das ändern der Größe der Zeichenfolge (D. H. eine Speicher-Zuordnung auftreten könnten)?

    • Also, ich benutze keine anderen memory allocation manager, außer standart. Die DLL und die EXE wurde zusammengestellt mit exakt den gleichen Einstellungen.
    • Es ist mehr als das. Sie müssen beide Module verwenden die gleiche Instanz der Laufzeitumgebung.
    • Die gleiche Instanz der runtime... Was ist das?
    • Ja, in der Tat. Die gleiche Instanz.
    • In Ihrem Projekt-Einstellungen, müssen Sie die Laufzeitumgebung die DLL-version der Laufzeit. Wenn Sie nicht wissen, dann müssen Sie wissen, wie dies absolut notwendig ist, um Ihren code zu arbeiten.
    InformationsquelleAutor PaulMcKenzie
  2. 4

    C++ - Klassen, wie std::string verwendet werden können modulübergreifend, aber tun, so stellen erhebliche Einschränkungen auf die Module. Einfach gesagt, beide Module müssen die gleiche Instanz der Laufzeit.

    So, zum Beispiel, wenn Sie kompilieren eines Moduls mit VS2013, dann müssen Sie so tun, für das andere Modul. Was mehr ist, müssen Sie eine Verknüpfung zu der dynamischen Laufzeit eher als statisches verlinken der Laufzeit. Letztere Ergebnisse, die in unterschiedlichen Laufzeit-Instanzen in jedem Modul.

    Und es sieht aus wie Sie exportieren member-Funktionen. Das erfordert auch eine gemeinsame Laufzeitumgebung. Und sollten Sie __declspec(dllexport) auf die gesamte Klasse und nicht einzelne Mitglieder.

    Wenn Sie beide Module, dann ist es leicht genug, um diese Anforderungen zu erfüllen. Wenn Sie möchten, lassen Sie die anderen Parteien produzieren der eine oder andere der Module sind, dann sind Sie der Verhängung einer erheblichen Einschränkung für die anderen Parteien. Wenn das ein problem ist, dann erwägen Sie die Verwendung mehr tragbar interop. Zum Beispiel, anstelle von std::string verwenden const char*.

    Nun, es ist möglich, dass Sie bereits mit einem einzigen gemeinsamen Instanz der dynamischen Laufzeit. In dem Fall wird der Fehler prosaischer. Vielleicht sind die Aufrufkonventionen nicht übereinstimmen. Angesichts der spärlichen Niveau der Details in deiner Frage, es ist schwer, etwas zu sagen, mit Sicherheit.

    • Es ist genau aus diesem Grund, dass COM definiert eine schmale Reihe von (ziemlich unbequem) Arten und Regeln über das Objekt Eigentum. Die OP könnte wir gut beraten, die Forschung zu den Konventionen, da Sie eine robuste Lösung für dieses problem. Auch hervorzuheben, dass traditionell release und debug-builds sind nicht kompatibel bei der Verwendung von STL auf Windows (dies ist wegen der zusätzlichen sanity checks beim Bau für debug, wodurch Gegenstände von verschiedener Größe und layed out).
    • Das ist abgedeckt durch die "Nutzung der vernünftige Instanz von RTL". COM wäre eine gute Wahl hier. Binäre interop.
    InformationsquelleAutor David Heffernan
  3. 0

    Traf ich ähnliches problem.
    Ich beschloss, dass ich es synchronisieren Konfigurations-Eigenschaften -> C /C++ Einstellungen.

    Wenn Sie möchten debug-Modus:

    • Set _DEBUG definition in Präprozessor-Definitionen in beiden Projekten.
    • Set /MDd in der Code-Generation -> Runtime-Bibliothek in beide Projekte.

    Wenn Sie möchten, release-Modus:

    • Entfernen _DEBUG definition in Präprozessor-Definitionen in beiden Projekten.
    • Set /MD in-Code-Generation -> Runtime-Bibliothek in beide Projekte.

    Beiden Projekte, die ich meine, exe-und-dll-Projekt.

    Es funktioniert für mich, vor allem, wenn ich nicht wollen, ändern Sie beliebige Einstellungen der dll, sondern nur anpassen.

    InformationsquelleAutor wathson
Schreibe einen Kommentar