La regola d'oro è che si deve rilasciare dallo stesso mucchio che è stato utilizzato per allocare la memoria.
Se lo si assegna con malloc()
, è necessario deallocarlo con lo free()
dallo stesso C RTL. E allo stesso modo sul lato gestito, AllocHGlobal()
dovrebbe essere bilanciato da FreeHGlobal()
.
Ora, AllocHGlobal()
viene implementato chiamando la funzione Win32 LocalAlloc
. Quindi è possibile liberare tale memoria con una chiamata a LocalFree
sul lato nativo. E viceversa.
Se si desidera utilizzare un heap condiviso tra nativo e gestito, è più comune utilizzare l'heap COM. Sul lato nativo utilizzare CoTaskMemAlloc()
e CoTaskMemFree()
. Sul lato gestito utilizzare Marshal.AllocCoTaskMem()
e Marshal.FreeCoTaskMem()
.
Tuttavia, si dovrebbe evitare di progettare il sistema in questo modo. È molto più semplice attenersi a una regola che tutta la memoria allocata nel lato gestito viene deallocata lì, e allo stesso modo per il lato nativo. Se non segui questa regola, presto perderai traccia di chi è responsabile di cosa.
fonte
2012-01-26 22:40:13
Grazie per tutte le risposte – bzamfir
Grazie. In realtà quello che ho fatto è stato creare nelle mie funzioni lib esportate AllocateMem e FreeMem, che ho raccomandato di usare chiamando programmi, quando si creano strutture passate alla lib. Ma mi stavo chiedendo di non rispettare questa regola e passare alla mia lib alcune strutture allocate con malloc (o qualsiasi altra cosa), cosa dovrebbe accadere? – bzamfir
Il problema è che le strutture hanno alcuni puntatori al char (per le stringhe) che devo allocare e passare al codice chiamante. E se il codice chiamante tenta di liberare quella memoria con free()? Ecco perché ho creato FreeMem, che ho implementato con FreeHGlobal, per essere usato per rilasciare memoria nel chiamare prog. Altrimenti è la responsabilità del programmatore del codice chiamante. – bzamfir