Speicher allokieren für Parameter einer DLL

electron

Hallo,

ich präsentier hier mal mein bescheidenes Halbwissen und füge ein paar Fragen dazu.
Wenn man an eine Dll Parameter übergibt, dann sollte ausschliesslich der Aufrufer dafür Speicher allokieren und nicht innerhalb der Dll!?
Wenn die Dll einen Werteparameter zurück liefert, dann darf der Speicherbedarf nie größer sein, als der vom Aufrufer allokierte !?

So, nun hab ich aber ein ganz tolles Codekonstrukt entdeckt, dass (nur) bei Aufruf von Basic an C Dll funktioniert:

long FAR PASCAL strFunc(LPSTR *str1, LPSTR str2)
 {
    CString str(*str1);
    str = "vorn" + str + "hinten";
    BSTR *ole_str = (BSTR *) str1;
    SysReAllocString(ole_str, (BSTR) str.GetBuffer(str.GetLength()));
     return 0;//str.GetLength();
 }

Wieso funktioniert das, wenn der Aufruf von einer Basic EXE kommt??
Wieso crasht das, wenn der Aufruf von einer C++ EXE kommt??
Wie mach ich ein "GetString" richtig, wer allokiert mir am besten den speicher?? Und wie und wann geb ich ihn am besten wieder frei??

simon.gysi

Es ist wichtig, dass der Speicher dort freigegeben wird, wo er alloziert wurde (geht ja nicht anders).

D.h. new und delete für denselben Heap benutzen.
(-> Wenn eine DLL Funktion new benutzt, soll es auch eien DLL Funktion geben, die dass delete ausführt (od. Smart Pointer verwenden)).

Simon

Martin Richter

1. Wie kommst Du darauf, das man mit dem cast eines Zeigers ein gültiges Objekt auf dem Heap bekommt.

BSTR *ole_str = (BSTR *) str1;

casts sollten Dich stutzig machen. Man benötigt casts wirklich selten
2. Die SysAlloc... Gruppe ist eine eigene API Gruppe mitkomplett eigener Speicherverwaltung und dem speziellen Typ BSTR! Du dafst solche Zeiger nur mit den entsprechenden String Funktionen bearbeiten.
http://msdn.microsoft.com/en-us/library/ms221105(VS.85).aspx

@simon.gysi: Wenn er die SysAlloc... Funktionen nutzt, kann er allozieren und freigeben und in dem Prozess machen wie er will. Diese Funktionen verwenden einen eigenen prozessweiten Heap.

simon.gysi

@martin: ja, dann ist das ja sichergestellt. merci.

electron

Das Codebeispiel habe ich aus einem Onlinemanuskript:
'Writing C DLLs for use with VB'
Das dumme, BSTR ist ja eigentlich der typische VB String. Trozdem ersetzt VB die String Parameter an eine DLL mit char*. Daher der cast nach BSTR.
Das Thema mit BSTR und eigene Speicherverwaltung ist wohl auch der Grund, wesshalb mein Aufruf von VB->C Dll geht und von VC->C Dll crasht, da hab ich nämlich den Stringparameter mit malloc allokiert.

Übrigens, so solls angeblich auch gehen:

SysReAllocString(*&ppszString,"I safely modifed the length of the string.");

Das ist doch eigentlich auch ein cast, oder?

Meine 3. Frage ist mir übrigens am wichtigsten.

electron schrieb:

Wie mach ich ein "GetString" richtig, wer allokiert mir am besten den speicher?? Und wie und wann geb ich ihn am besten wieder frei??

Danke schonmal @simon, @Martin

Martin Richter

electron schrieb:

Übrigens, so solls angeblich auch gehen:
SysReAllocString(*&ppszString,"I safely modifed the length of the string.");
Das ist doch eigentlich auch ein cast, oder?

1. Ist das ken cast. Wo siehst Du hier dnen einen?
2. Funktioniert das korrekt wenn ppszString ein korrekter BSTR ist!
3. Ist das *& doppelt gemoppelt.

Meine 3. Frage ist mir übrigens am wichtigsten.

electron schrieb:

Wie mach ich ein "GetString" richtig, wer allokiert mir am besten den speicher?? Und wie und wann geb ich ihn am besten wieder frei??

Danke schonmal @simon, @Martin

[/quote]

Was soll GetString tun? Einen String allokieren?
SysAllocString

Ich habe Dir doch einen Link, auf die entsprechenden API Funktionen gepostet:
http://msdn.microsoft.com/en-us/library/ms221105(VS.85).aspx
Was ist Dir daran unklar? Werde bitte etwas präziser in Deiner Fragestellung.

Ich lese/schreibe mit einer DLL in eine XML Datei. Die Aufrufer der Dll sind Basic Applikationen und C++ Applikationen.
Beim lesen aus der XML weiss der Aufrufer nicht wie groß die Daten sind. Beim schreiben ist das ganze ja trivial.