Speicher reservieren und freigeben in DLLs

Das sollte eigentlich kein Problem sein.
Der mit free() freigegebene Speicher muß im selben
Prozeß allokiert worden sein; in welcher DLL oder im
Hauptprogramm ist egal.

Vielleicht wird er versehentlich zweimal freigegeben?

Viele Grüße,
Klaus

Hängt ganz davon ab, ob es der gleiche Speichermanager ist. Gäbe es nur 
einen, dann bräuchten die ganzen WinAPI Aufrufe (z.B. kernel32.dll) 
keine Buffer und Buffergrößenangaben. Die WinAPI umgeht dies Problem 
grundlegend so, dass sie die Buffer immer vom Aufufer gestellt haben 
will (Ausnahme IMalloc Interface in der Shell).

Es gibt keinen Standard oder Interface für den Abgleich der 
Speichermanager. Und da DLL schlecht vorschreiben können wer sie lädt, 
bringen sie im Normalfall einen Speichermanager mit. Visual Studio 
Projekte referenzieren immer die runtime Library DLL und somit benutzen 
sie indirekt den gleichen Speichermanager, da er in dieser DLL enthalten 
ist.

Aber so oder so ist die Grundsatzregel: Speicher immer dort freigeben wo 
er alloziiert wird. Das bedeutet nicht nur das gleiche Modul sondern im 
Normalfall auch die gleiche Ebene. Finally Anweisungskonstrukte wurde ja 
in vielen C++ Anbietern als eigene Spracherweiterung nachgereicht.

Wird der Speicher mit den CRT-Funktionen (m)alloc und free verwaltet, 
oder vielleicht doch mit den Win32-API-Funktion GlobalAlloc und 
GlobalFree? Die darf man keinesfalls vertauschen.