Newsgroup: it.comp.programmare.win32
Titolo: Memoria & DLL

Salve a tutti,
Ho realizzato una DLL utilizzando il C++ Builder 4.0 (SP2) con dentro alcune
classi.
Ho poi tre applicazioni che linkano (staticamente attraverso la .lib) la
DLL. 2 funzionano, 1 mi da problemi.
Il problema è un access violation e si verifica (da debug) sul distruttore
di qualche oggetto perchè avviene sull'uscita di una funzione.
Il bello è che se includo nel programmino malfunzionante il file .cpp e .h
di una classe che utilizzo (già presente nella dll) direttamente
nell'applicazione, funziona.
Questa classe esegue alcune malloc/realloc/free/memcpy su dei buffer.
La domanda è: Esiste qualche accorgimento sulla gestione della memoria in
una DLL ????
--
Bye Lvca.
* Personal:
   E-mail:   
l.ga...@tin.it
   HomePage: 
http://space.tin.it/clubnet/lgarulli/
* Member of Linux User Group - ROME (ITALY)

di qualche oggetto perchè avviene sull'uscita di una funzione.
Risposta stupida : hai gia incluso nel progetto la lib MEMMGR.LIB
(sial il progetto della DLL che del chiamante ?)
Questo ti vincola pero' a distribuire la DLL BORLNDMM.DLL col tuo
ptogramma.
Anch'io ho avuto un problema simile al tuo e derivava dal fatto che
allocavo l'oggetto nella funzione DllEntryPoint() nel PROCESS_ATTACH.
Ho spostato l'allocazione/delete direttamente nel corpo della funzione
che esportava la DLL ed e' andato tutto OK.
Questo e' il mio caso non so quanto corrisponde esattamente al tuo.
 
//-------------------------------------------------
// Gianluigi Rubino 
cman...@altavista.net
// C++ Maniacs : 
http://welcome.to/c++maniacs
//-------------------------------------------------


Scusa ma non ho capito.
Per essere + specifico il problema si verifica all'interno di una classe
template.
che (purtroppo) devo esportare sia il .h che il .cpp.
Io dapprima pensavo che le malloc/realloc/free dovessero essere fatte nella
DLL, così x evitare che le classi template allocassero nell'heap del
programma ho sostituito le malloc/free/realloc con metodi statici di una
classe MemoryManager contenuta nella DLL. Risultato ? Niente!
Non sarà il Builder bacato ?
Ciao, Luca.

 una DLL ????
Un bug tipico e` fare malloc (o new, o ...) da un modulo (DLL o EXE
che sia) e free (o delete, o ...) da un modulo diverso.  Questo non
dovrebbe succedere se una classe vive interamente entro un dato
modulo (ad es una DLL), ma l'esistenza, ad esempio, di funzioni inline
(magari implicite...) puo` causare problemi.  I tuoi sintomi paiono
tipici di questo "bug tipico".
Se dici a tutti i moduli che compongono la tua applicazione di usare
una versione DLL delle librerie di runtime del C/C++, puo` essere che
le cose vadano a posto (cosi` e` con MSVC++, perche` in quel caso
si finisce per usare la stessa heap per tutte le allocazioni, da qualsiasi
modulo esse vengano fatte; non so se Borland si comportera` nello
stesso mood, ma val certo la pena di provare).
L'alternativa e` quella di usare funzioni per l'allocazione che, a basso
livello, peschino, alla fin fine, non sulle API come HeapAlloc ecc (che
possono usare heap diverse -- il che e` efficiente, ma ti vincola a
garantire che l'allocazione e il rilascio di un singolo "grumo" di memoria
avvengano sulla stessa heap!), bensi` su quelle come CoTaskMemAlloc,
ecc, studiate apposta per permettere invece che un dato "grumo" di
memoria sia allocato in un componente e rilasciato in un componente
diverso.
E` un grosso problema ottenere questo relativamente alle malloc/free/...
del C, perche` non sono proprio studiate per permettere di modificare
i bassi livelli su cui si appoggiano.  In Standard C++, invece, usando quindi
new e delete, l'operazione e` relativamente indolore, visto gli operator new
e operator delete sono appositamente progettati per simili override (che
puoi fare "globalmente", e/o classe per classe).
Alex