Dll Hell

[DraKKaR]

 Algunos problemas de punteros que he tenido en el motor me han llevado a pensar que toda la memoria que se reserve dentro de una DLL (dentro de funciones implementadas en una DLL) tiene que liberarse dentro de la misma DLL (por cuestiones del heap)... me gustaría saber si eso es así o no tiene porqué.

Gracias.

[sés]

 Quizás te ayude GlobalAlloc().

[Astharoth]

 
Depende.

Una dll puede tener la crt dentro o usar la crt externa (msvcrt.dll si hablamos de VC).
Si tiene la crt interna (compilada estaticamente)  en su entrypoint al iniciarse, crea un heap para las funciones de memoria (new,delete,free,malloc,etc) y todas las llamadas iran contra este heap... asi que, si se intenta liberar ese puntero desde un heap que no es el suyo.. pues eso, "invalid pointer to deallocate".

Si la dll usa la crt externa (msvcrt) ya no tiene dicho problema ya que cuando se carga msvcrt, inicializa un heap para sus funciones exportadas de memoria .. estas son usadas por todos los modulos la aplicacion que importen msvcrt (por ejemplo si tienes 3 dll's que usan msvcrt, estas 3 dll's usaran ese heap y esas funciones de memoria).

Otra opcion es gestionarte el tema tu mismo con tus propias funciones de memoria (creandote un heap, pillando toda su memoria y administrandotela tu mismo)... o usar las funciones genericas del api de win32 (no las ansi c).. como apuntan por aqui.. pues un globalalloc por ejemplo..
Tambien puedes crearte tu un heap (CreateHeap) y dejar el handle al heap en una variable shared,etc,etc.. vamos, posibilidades mil.. todo depende de lo que uno vaya a hacer.

Particularmente yo prefiero.

- Para recursos "estaticos" (lease graficos, sonidos,etc,etc) usar mi propia gestion de memoria (con mi heap,etc,etc)
 de esta forma puedo usar estrategias de alocacion de memoria adecuadas para esos tamaños y controlarmelos a mi rollo.

- Para datos temporales, recursos de trapicheo,etc.. vamos, tipico array , tipica estructura temporal de conversion,etc,etc...
 uso un heap para cada dll (msvcrt estatica) de forma que si meto la pata y tengo un leak , con cosas como el processexplode (viene con el visual) puedo ver exactamente que modulo esta tragando memoria y asi ir aislando el leak (imprescindible cuando hablamos de aplicaciones relativamente grandes... 10/12 dll's , varios procesos y un buen porron de lineas de codigo > 180.000)..

Un Saludete :)

[DraKKaR]

 El problema del GlobalAlloc es que no quiero casarme con ningún API concreto y prefiero ir por estándares. Y lo de programar mi propio heap con todas las funciones para reservar y liberar memoria no me convence. Ya sé que así tendría más control sobre la memoria , pero no quiero reinventar tanto la rueda.

Lo que he optado al final es asegurarme de que toda memoria que se reserva en una DLL, se libere en la misma. Creo que conseguir eso es símbolo de una interfaz consistente y sólida. Tenía un problemay de esta forma se ha resuelto.

Sin embargo, lo del heap local para trapicheos y memoria temporal a nivel de DLL me ha gustando basatnte, para aislar el origen del error. Sin embargo mi motor no consta de tantas DLLs como para implementar eso. Por ahora me las apaño así...

Gracias por responder...