Existe un modo de que la dll tenga su propia memoria. En ese caso no serviria. Si la usas simpelemente como libreria linkeada dinamicamente no hay problema. De todos modos no me suena elegante...es inevitable?
2008/2/20 Leandro Lucarella <[EMAIL PROTECTED]>: > personaje, el 20 de febrero a las 01:23 me escribiste: > > 2008/2/20 Leandro Lucarella <[EMAIL PROTECTED]>: > > > personaje, el 19 de febrero a las 17:01 me escribiste: > > > > > > > > > > 2008/2/19 Leandro Lucarella <[EMAIL PROTECTED]>: > > > > > personaje, el 19 de febrero a las 15:05 me escribiste: > > > > > > > > > > > > No estoy 100% seguro pero no creo que tengas problemas en ese > > > caso. El > > > > > > > problema lo podés tener si el new lo hacés de objetos con > > > destructor, > > > > > > > porque en ese caso el delete no va a llamar al destructor. > > > > > > > > > > > > > > > > > > > nono, sólo tipos de dato numericos. > > > > > > > > > > > > lo que decís de los destructores está bien y lo tengo en cuenta. > > > > > > > > > > Igual no sé si el delete no guarda algún tipo de dato de tipos. Yo > > > que vos > > > > > si me hago el piola con void*s uso malloc y free. new y delete no te > > > > > proveen nada útil en estos casos. > > > > > > > > Me parece que tenés razón... conviene malloc. > > > > > > > > Ahora, hay algún problema si el malloc se hace en un dll y el free en > > > otro? > > > > > > No veo por qué habría de haberlo, el proceso es uno solo. > > > > Aparentemente, al menos con objetos, puede llegar a ser un problema... > > lo consulto con la almohada y te cuento mejor mañana. > > En el peor de los casos tendrás que hacer una función free_xxx() en tu > biblioteca compartida y llamar a es en vez de a free(), pero realmente, > siendo que free() está en una biblioteca compartida (libc) no sé si tenga > mucho sentido. Pero tampoco estoy completamente seguro del asunto. > > -- > Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ > ---------------------------------------------------------------------------- > GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) > ---------------------------------------------------------------------------- > aFR [EMAIL PROTECTED] has quit IRC (Ping timeout) > > _______________________________________________ > Lista de correo Programacion. > [email protected] > http://listas.fi.uba.ar/mailman/listinfo/programacion > > _______________________________________________ Lista de correo Programacion. [email protected] http://listas.fi.uba.ar/mailman/listinfo/programacion
