Liberación en un atexit()
memory free (8)
no liberar memoria antes de la finalización del proceso no es una pérdida de memoria. es una pérdida de memoria cuando pierdes el control. pero la memoria no es el único tipo de recurso, y otros recursos persisten en todos los procesos (como manejadores de ventanas y manejadores de archivos), por lo que es necesario que los "libere".
¿Hay algún punto para liberar memoria en una función atexit ()?
Tengo una variable global que se malloc''ed después del inicio. Podría escribir una función atexit () para liberarla, pero ¿no va a recuperar el sistema toda esa memoria cuando el programa salga de todos modos?
¿Hay algún beneficio de estar ordenado y de limpiarlo yo mismo activamente?
En Windows, algunas llamadas devuelven memoria que pertenece al sistema operativo o a COM y necesita liberar esa memoria explícitamente o no se liberará incluso después de que finalice su proceso. Pero este es un escenario raro.
En todos los sistemas operativos modernos, puede suponer con seguridad que toda la memoria se liberará cuando el programa finalice.
No en C: es como reorganizar las tumbonas mientras el barco se hunde a tu alrededor.
En C ++, la respuesta es diferente, porque los objetos pueden eliminar archivos temporales y demás en sus destructores, por lo que debe asegurarse de que se los llame.
Un beneficio de liberarlo es que si alguna vez realiza alguna prueba de fuga de memoria que intenta emparejar asignaciones con desasignaciones durante la vida del proceso, no obtendrá falsos positivos de este tipo de fuga deliberada.
Debería liberar () si su código que está llamando atexit () es parte de una biblioteca compartida cargada dinámicamente (con dlopen (), por ejemplo). En este caso, el controlador atexit se invocará en dlclose () para que el almacenamiento dinámico continúe existiendo durante el resto del proceso.
Al ver que malloc() / free() normalmente involucra estructuras de datos extensas que existen en el espacio de usuario, la memoria free() cuando termina el programa) puede ser una pérdida de rendimiento. Si las partes de la estructura de datos se localizan en el disco, solo se deben cargar desde el disco para descartarlas.
Mientras que si termina sin free() ing, los datos paginados en el disco pueden morir en paz.
Por supuesto, free() en otros momentos suele ser beneficioso ya que otros malloc() pueden reutilizar el espacio que liberaste y free() incluso puede desasignar alguna memoria que luego puede ser utilizada por otros procesos.
En realidad, estar en orden puede ser interesante cuando su programa evoluciona. Le obliga a escribir la función de limpieza cuando crea funciones de "inicialización". El beneficio se produce cuando su programa se vuelve más complejo y desea reiniciar parte del programa. Si ya ha escrito las funciones de limpieza de trabajo, es menos probable que haya olvidado de repente algo de limpieza al "reiniciar" parte de su programa.
Escribir funciones de limpieza "perezosamente", es decir, solo cuando lo necesite es más propenso a errores. Las funciones de limpieza de escritura lo obligan a pensar en la limpieza y la eventual dependencia de limpieza. Permite una reutilización de código más sencilla de una parte de tu código en otro proyecto.
Así que sí, la liberación en un atexit es inútil, y también lo es el descriptor de archivo de cierre. Sin embargo, escribir y mantener la función de limpieza a medida que crece su código puede ser una restricción que lo forzará a pensar sobre lo que está haciendo.