Newsgroup: it.comp.lang.c++
Titolo: Passare a dll riferimenti a oggetti stl

Buongiorno a tutti,
ho letto che non è possibile allocare memoria in un modulo e disallocarla 
in un altro modulo, così mi chiedo, ma se passo un std::vector ad una dll 
e me lo faccio riempire, lui allocherà memoria.
Se lo passo ad una funzione della dll per riferimento e me lo faccio 
riempire, lo uso, poi esco dallo scope nel chiamante e quindi distruggo 
l'oggetto nel chiamante...succederanno casini (provato, è così).
Ma allora mi chiedevo, non c'è modo per creare una libreria (dll) a cui 
passo per riferimento oggetti della Standard Library?


Hai provato a costruire gli oggetti stl con un allocator definito da te 
(che l'oggetto poi si porta dietro) ? L'idea sarebbe quella di 
allocare/deallocare memoria da un pool di oggetti preallocato da te.
C'e' spiegazione ed esempio nello Stroustrup al para Allocators (19.4 
nella mia edizione). Scusa se non ti do' piu' info ma piu' di Stroustrup 
mi sembra dura :). Dovrebbe fungere.
Ciao,
Gio

 Gio
Ok, adesso guardo la soluzione. Il libro ce l'ho sempre a portata, 
naturalmente :-) Grazie!

 l'oggetto nel chiamante...succederanno casini (provato, è così).
Eggià.
Programmando con COM sotto windows si verifica lo stesso problema: e 
Microsoft ha risolto infilando un allocatore apposta nel sistema COM, 
che è la soluzione di cui parlava gio.
Se un oggetto COM alloca un dato X in memoria e ti restituisce il 
puntatore o il reference e NON lo disalloca quando non ti serve più, tu 
devi chiamare
CoGetMalloc(1, pIMalloc);
per ricavarti il puntatore all'allocatore COM IMalloc, e poi:
pIMalloc->Free(X);
e sei a posto...


Ma, scusa l'ignoranza, è un limite della gestione della memoria 
all'interno delle dll di windows, oppure il problema si verifica in 
tutte le librerie a chimata dinamica?

 tutte le librerie a chimata dinamica?
E' un "problema" "concettuale". Si chiama "progettazione di un'interfaccia".
Un interfaccia è un contratto tra due signori C e S.
I due tizi bisogna che si mettano d'accordo su cosa scambiarsi e come.
Purtroppo si tende a semplificare e a considerare "interfaccia" il 
semplice elenco di firme di funzioni pubbliche di una classe.
In certi casi (quando l' "ambiente" in cui operano C e S è lo stesso o 
sufficientemente compatibile) può bastare. In generale no.
Bisogna tenere conto come minimo del modello di threading, della 
gestione della memoria e di come eventuali librerie dinamiche linkate 
sia da C che da S possano sopravvivere quando linki C e S...
La conoscenza di COM è una buona scuola perchè tutti questi aspetti sono 
messi in luce e "formalizzati" per benino. L'unico problema è che COM è 
difficile da capire e da digerire... ma lo è perché è difficile 
l'argomento in se!
Tornando alla questione della memoria: se S fornisce memoria a C, 
bisogna che i due siano d'accordo su come deallocarla.
Ad esempio
1 - ci pensa S a deallocarla.
2 - assieme alla memoria S fornisce il "deallocatore"
3 - C e S usano lo stesso identico heap
...

 stesso identico heap ...
Ma non esiste una soluzione relativa alle standard library?
Ovvero, se io linko una dll dinamica ad una eseguibile, passando un 
std::vector in modo che la dll me lo riempia, ed entrambi sono stati 
compilati con la versione xxx di gcc, non dovrebbe funzionare?
Non hanno lo stesso allocatore/disallocatore?