¿Cuándo exactamente un archivo DLL usaría un montón diferente al ejecutable?

Sé que si sus enlaces estáticos de DLL contra una versión diferente del tiempo de ejecución, entonces crea su propio montón. También lo hará si se le ordena hacer un montón. En estas circunstancias, no es seguro para el DLL eliminar lo que el exe asignó. ¿En qué casos NO se aplica esto (como en, es seguro que el DLL elimine lo que el exe asignó)? ¿Es seguro si tanto el exe como el enlace estático de DLL están en contra de la misma biblioteca de tiempo de ejecución?¿Cuándo exactamente un archivo DLL usaría un montón diferente al ejecutable?

Gracias

básicamente hay una manera en que el que asigna sólo podía hacer addEvent(new DerivedEvent(), FunctorDestroyClass());

Fuente

2011-01-10 jmasterx

No. Esta es la razón por la que dinámicamente se vinculan con el tiempo de ejecución. Este es el comportamiento estándar (vinculación dinámica) y la única forma recomendada por MS. vincular estáticamente el tiempo de ejecución solo causa dolores de cabeza. Simplemente no lo hagas. –

que puedan estar leyendo más en su pregunta que está ahí, pero si estás interesado en saber cómo se puede asignar y liberar memoria a través de fronteras DLL, a continuación, se usa algo como lo siguiente:

#define DLLMemAlloc(size) HeapAlloc(GetProcessHeap(), 0, size) 
#define DLLMemFree(mem) HeapFree(GetProcessHeap(), 0, mem)

Eso podría ser más seguro (un intento parcial de prueba de futuro). Confiar en varias opciones de construcción para garantizar la seguridad de la asignación y la liberación a través de los límites puede generar problemas.

Y (también no es parte de la pregunta), puede volver a pensar si es realmente necesario para poder hacer esto. Parece que puede haber un error de diseño si una DLL tiene que asignar algo que otra DLL (o ejecutable) tiene que liberar.

Fuente

2011-01-10 17:56:53

Es porque quiero hacer eventos polimórficos cronometrados, por lo que no existe una forma de fábrica para hacer esto, y si el usuario no tiene forma de controlar el tiempo, no sabrá cuándo liberarlo, razón por la cual la DLL también lo necesita. – jmasterx

Estoy de acuerdo. No creo que puedas asignar de un lado y libre del otro y dormir bien por la noche, incluso si funciona bien en el momento en que te morderá el culo algún día. –

@Milo DLL puede exponer una interfaz de limpieza y EXE puede usarlo para liberar en lugar de simplemente usar una llamada gratuita(). –

DLL lo obtendrá es propio administrador de memoria si se vincula la biblioteca de tiempo de ejecución de forma estática. Tiene 3 opciones: vincular el tiempo de ejecución dinámicamente, asignar y desasignar siempre en el mismo lugar (ya sea DLL o ejecutable, proporcionando el reenvío si es necesario), o utilizar un asignador de memoria de terceros que resuelva este problema.

Fuente

2011-01-10 17:50:38

Entonces, si el DLL se vincula dinámicamente con el tiempo de ejecución de MSVCR80.DLL, entonces el exe se vincula dinámicamente con MSVCRT90.DLL, ¿no hay problema? – jmasterx

Definitivamente lo es si no son la misma versión. No debe confiar en que dos módulos tengan el mismo montón. – Puppy

@Milo no debería haber un problema a menos que trate de asignar por un lado y liberar por el otro, pero no lo he probado yo mismo (tm). –

¿Cuándo exactamente un archivo DLL usaría un montón diferente al ejecutable?

Respuesta

Cuestiones relacionadas