c++ - programacion - ¿Por qué recursos gratuitos si el programa ya está saliendo?

manual de programacion android pdf (18)

Muchas bibliotecas como SDL, etc, etc. tienen en sus tutoriales el método de llamadas que liberan recursos justo antes de salir del programa, pero que yo sepa, la mayoría de los sistemas operativos liberan toda la memoria de los procesos cuando se cierran, ¿por qué tengo que molestarme en hacerlo? ¿Si la aplicación va a salir de todos modos?

Bueno, en su mayoría es cierto que hoy en día casi todos los sistemas operativos principales liberan todos los recursos (o la mayoría) que un programa ha asignado al finalizarse. Sin embargo, esto no es cierto, en primer lugar, para todos los recursos (por ejemplo, en mi Mac, los sockets abiertos permanecen abiertos durante un tiempo cuando no se cierran correctamente al finalizar el programa) y, en segundo lugar, creo que no para todos los sistemas operativos.

Históricamente, los sistemas operativos no molestaban en absoluto (especialmente algunos de los sistemas operativos más antiguos de 16 bits), por lo que la limpieza de todos sus recursos al finalizar la programación se ha convertido y sigue siendo una buena práctica de programación, y un programador que no limpia sus cosas generalmente se considera un mal programador.

Cada vez que se inicia un nuevo proceso, se le asigna algo de memoria. La memoria puede ser de cuatro tipos como:

1.Heap 2.Local 3.Virtual 4.Global

Local generalmente se usa para las direcciones de la variable main () porque estas variables principales se usarán con frecuencia. Global mantiene el registro de variables globales. La memoria del montón se asigna (las páginas se asignan) a los programas o procesos y tiene la información de los datos y funciones del programa.

Lo que realmente sucede es que el sistema operativo utiliza el concepto de punteros. Y siempre que en el puntero del programa comience a apuntar a otra memoria (debido a un error de código) y deje de apuntar a la ubicación de la memoria anterior, el último espacio de la memoria aún se está utilizando en la memoria del montón. pero este espacio de memoria no sirve de nada. Cuando sale cualquier programa, libera la memoria según la ubicación de sus variables y funciones. Pero como le dije a la memoria no apuntada todavía tengo datos, pero nadie la apunta, así que el programa no puede liberarla.

Para liberar esa ubicación de memoria no utilizada usamos free (). Como malloc, realloc, calloc, free, todas son funciones de la memoria de pila. Cuando lo llamamos gratis, borra las páginas que fueron asignadas para el programa y también libera esa memoria no utilizada.

In simple words,

50-100 ubicación de memoria asignada a su programa. ayb (las variables en su programa) apuntan a 60 y 70. debido a un error de código, b comienza a apuntar a 60. Entonces a y b apuntan a 60. Nadie señala a 70 ahora. Cuando el programa comience a salir, obtendrá la ubicación de la memoria de a y la liberará. Luego obtendrá la ubicación de la memoria de b y la liberará. Pero el programa nunca llegará a conocer la ubicación de 70 porque nadie la apunta. No se libera la memoria de los 70.

Mientras que cuando llamas gratis (), libera directamente toda la página y con esa memoria de 50-100 se liberará. Ahora, tanto las ubicaciones de memoria no puntiagudas como las puntiagudas son de uso gratuito.

Hoy en día los idiomas tienen recolector de basura para hacer la función de la libre (). Pero si hablamos de los sistemas operativos, entonces tienen que hacerlo por sí mismos, de modo que en las bibliotecas siempre se use gratis. Y también es la mejor manera de escribir código.

Como señalan las otras respuestas, hay una diferencia entre los recursos y la memoria. Solo puedo hablar en el contexto de la API de Win32, pero estoy seguro de que conceptos similares son aplicables para bibliotecas como SDL. Algunas bibliotecas pueden proporcionar la liberación automática de recursos, otras pueden no. Siempre es una buena práctica liberar sus recursos independientemente. Los recursos específicos del dispositivo son un ejemplo de recursos que pueden causar problemas si no se liberan. Es posible que desee consultar la documentación de su biblioteca para obtener detalles sobre la administración de recursos.

Como usted sabe, dependiendo del sistema operativo, la memoria es generalmente (¡espero que sí!) Se libera automáticamente cuando el proceso finaliza.

Sin embargo, muchas bibliotecas, como SDL, le piden al sistema operativo que asigne recursos del sistema que no se liberen de manera oportuna (tal vez ni siquiera hasta el cierre) a menos que la aplicación las libere explícitamente .

Además de ser amable con el sistema operativo y limpiarlo, liberar cualquier memoria que asigne es importante en cualquier aplicación que se ejecute durante un período de tiempo desconocido porque esa memoria ocupa el espacio que otras aplicaciones podrían necesitar.

También es un buen hábito para limpiar después de ti mismo. :)

El sistema operativo intenta liberar todos los recursos que aún se mantienen en un proceso después de que se cierre como un último esfuerzo para mantener el sistema en funcionamiento. Se supone que las aplicaciones se limpian después de sí mismas, pero la limpieza automática del sistema operativo está diseñada para detener los programas mal escritos que eliminan todo el sistema por pérdidas de memoria, archivos retenidos, etc. Por lo tanto, no debe confiar en él como el modo predeterminado para su aplicación. para ser cerrado! Idealmente, el sistema operativo nunca tendrá que limpiar después de que un proceso se haya cerrado, porque todos los programas deberían estar bien escritos para limpiar después de ellos mismos. Sin embargo, en la práctica, algunos programas tienen errores o simplemente están mal escritos y es una característica útil para que el SO limpie después de estos programas perezosos.

Además, el sistema operativo no limpiará algunos recursos de todos modos. Si escribe un archivo en el disco y tiene la intención de eliminarlo cuando se apaga, el sistema operativo no lo eliminará automáticamente (¿qué pasaría si fuera el documento del usuario?). Pero si no lo limpia usted mismo, su programa ha perdido espacio en el disco de forma permanente. Hay muchos otros ejemplos para otros tipos de recursos que no sean archivos.

Así que no escriba un software malo que asume que el sistema operativo se limpiará: probablemente no lo haga al 100%, y ese mecanismo es solo para software de mierda. ¡Escribe buen software en su lugar!

En general, estoy de acuerdo con lo que otros han dicho: si no practicas buenos hábitos en las pequeñas cosas, también fracasarás con las grandes. Sin embargo, su pregunta sonó (una vieja) campana, sobre software de crash-only .

Si bien ese concepto se extiende "un poco" más allá de su pregunta original (no solo se ocupa de los recursos del sistema operativo, sino de los suyos (archivos abiertos, etc.), es posible que aún le interese.

La idea básica es, si el software no debe destruir los datos del usuario, etc. en caso de una caída (piense en las bases de datos / registros de tx, etc.) por qué incluso debería diseñar / programar una ruta de salida limpia. Si necesita reiniciar, vuelva a ejecutarlo, también puede "dejar que se bloquee".

Bueno, supongo que uno puede discutir las virtudes de eso todo el día, pero es interesante a pesar de todo.

En primer lugar: el sistema operativo no libera todos los recursos cuando finaliza el proceso, por ejemplo:

Archivos: a veces puede eliminar los archivos que ha abierto.
Recursos con nombre: exclusión mutua con nombre, memoria compartida, etc., etc.
Configuraciones de estados de aplicaciones más complejas, estadísticas y mucho más.

Así que una vez que administras todos los recursos de la misma manera, estás haciendo lo correcto.

Es una buena idea poner en orden después de ti mismo.

Para uno, la liberación de recursos ordenará los descriptores de archivos / conexiones de red / memoria compartida, etc. de manera controlada.

En segundo lugar, si está utilizando algo como la purity , puede asegurarse de que se tenga en cuenta toda la memoria, dando así una mejor idea de que no se producen pérdidas de memoria.

Estos son buenos modales.

Y nunca se sabe si desea convertir su programa en algo que se ejecute de forma persistente una y otra vez en el futuro.

Dicho esto, no es obligatorio y, como siempre, puedes romper las reglas si sabes lo que estás haciendo.

Incluso si su sistema operativo (no todos lo hacen) libera memoria al salir, hay algunas razones:

es buena manera
agrega simetría, por lo que el código se ve mejor
El sistema operativo no libera automáticamente algunos recursos al salir, como dispositivos (sensores, escáneres ...)
Si alguien toma este código y lo coloca en un programa que usa las bibliotecas solo en una pequeña parte de su tiempo de ejecución, los recursos serán gratuitos cuando no sean necesarios.
Si está buscando fugas de memoria defectuosas , su depurador no encontrará estas importantes.

La memoria y los recursos no son lo mismo.

La memoria se libera automáticamente.

Los recursos pueden, o no, ser liberados automáticamente.

La sensación de liberar la memoria incluso para los objetos cuya vida útil corresponde a la de una aplicación es inmediatamente obvia una vez que intenta encontrar una pérdida de memoria con Valgrind o algo así, ya que su salida se inundará con informes sobre esos objetos. Después de todo, una fuga sigue siendo una fuga.

No es necesario liberar memoria cuando se cierra la aplicación. El sistema operativo se encarga de recuperar la memoria. Como han mencionado otros, los recursos como la impresora, los archivos requieren liberar sus bloqueos para permitir que otros programas accedan a ellos.

Diga si su código no libera ninguna memoria (incluso cuando se ejecuta) y cuando aumente el tamaño de su código / proyecto, consumirá toda la memoria de su sistema y el mantenimiento será difícil de reparar. Por lo tanto, para todos los propósitos futuros, es una buena práctica liberar la memoria.

Sé que llego tarde a la fiesta, pero por favor libere toda su memoria y recursos, si no por otra razón que no sea porque cuando obtiene una pérdida de memoria real, como dentro de un bucle, lo último que necesito es su basura. abarrotada de mi memoria perfiladores de salida como valgrind.

En segundo lugar, limpiar la memoria no es un problema, use punteros inteligentes que hacen todo el trabajo por usted con poca o ninguna sobrecarga.

Finalmente, esto es aún más inexcusable si se trata de una biblioteca, no me importa si no es una fuga continua (es decir, 1 desperdicio de basura, por ejemplo: la creación de un singleton) una biblioteca no debe dejar datos en el almacén libre.

Si los recursos asignados a un programa se reclamarán o no dependerá de los sistemas operativos. Tenga en cuenta que específicamente algunos sistemas embebidos no liberan los recursos.

La mayoría de los sistemas operativos reclaman y liberan los recursos asignados, pero es una mala práctica confiar en el comportamiento del sistema operativo para esto y, por lo tanto, debe liberar todos los recursos adquiridos antes de salir del programa.

Supongo que lo primero que debe mencionarse es que no todos los recursos son iguales.

Ninguna de estas estructuras (en la mayoría de los sistemas operativos) se limpia automáticamente al cierre de la aplicación:

Pools de memoria compartida
Nombrado Win32 Mutex / Semáforo / Evento / etc. objetos
Ciertos tipos de conexiones de zócalo
Estructuras de datos del controlador de dispositivo de hardware propietario (oscuro)

... y estoy seguro de que me estoy olvidando de algunos.

En lo pequeño, puede ser fácil saber si su aplicación utiliza alguno de estos tipos de objetos y lo controla. Sin embargo, en aplicaciones más grandes, no es difícil llegar a un punto en el que tenga un subsistema profundamente integrado (¿un tercero?) Que asigne una o más de estas estructuras especiales y si el resto de su aplicación se filtra como un tamiz, usted podría estar en problemas

Es realmente una cuestión de disciplina de ingeniería que dice que su aplicación debe limpiarse después de la salida. Puede que no lo necesite ahora, pero podría apreciarlo más adelante a medida que su aplicación crezca.

Una de las razones que veo es:

Suponga que tiene las fugas de memoria volcadas en la ventana de salida de su entorno de desarrollo al salir de la aplicación. Si no "limpia" de manera adecuada, tendrá problemas para detectar las verdaderas fugas de todas las fugas que provienen de "no molestar".

Usted tiene razón, la mayoría de los sistemas operativos modernos liberarán memoria, manejadores de archivos, etc. cuando la aplicación salga. Así que estaría totalmente de acuerdo con usted y no me molestaría en liberar recursos si los recursos disponibles para las aplicaciones fueran ilimitados .

El hecho es que los recursos no son ilimitados, en realidad es todo lo contrario, por lo que cualquier cosa que tome es algo que otra aplicación que se ejecuta en el sistema no puede tener. En muchos casos, necesitará un recurso durante toda la vida útil de su aplicación, pero solo para una parte, por lo que desea jugar bien con el resto del sistema y tomar solo lo que necesita mientras lo necesita.

La práctica de no liberar recursos es muy común en los dispositivos integrados, ya que para estos la aplicación es lo único que se está ejecutando, y ni siquiera se puede salir, la única salida es apagar el dispositivo. Trabajo con uno de estos sistemas, y aunque el dispositivo integrado no tiene problemas para no lanzar cosas, los ingenieros sufrimos por varios motivos:

Al probar la aplicación integrada en una PC normal, nos vemos obligados a modelar el dispositivo simulado como un proceso que comienza y finaliza. Si los recursos se liberaran correctamente, podríamos tener un solo proceso que ejecutara varias pruebas en la misma ejecución, incluidas las pruebas que inician y detienen el dispositivo simulado.
en algún momento tuvimos que trabajar en un proyecto que requería que formáramos parte del código integrado y lo publicáramos como una biblioteca de enlace dinámico para Windows / Linux que realiza un subconjunto de las funciones del dispositivo real, pero sin el dispositivo real. Debido al problema de los recursos, los usuarios no pueden cargar y descargar esta DLL varias veces en sus aplicaciones, porque cada vez que lo hacen se toma una parte decente de la memoria y nunca se libera. Lo hemos documentado como una limitación, pedimos a nuestros usuarios que vinculen la biblioteca a la aplicación en lugar de cargarla dinámicamente. Desafortunadamente, después de más de 10 años de que este dispositivo integrado ha estado en desarrollo, sería muy complicado localizar y reparar todas estas asignaciones de recursos, por lo que seguimos postergando y tenemos un producto por debajo del óptimo.
cuando utilizamos herramientas de análisis de código estático y dinámico para localizar defectos reales, obtenemos un montón de falsos positivos, tantos que tuvimos que desarrollar herramientas que los filtran para no arriesgarnos a perder los reales en todo el ruido.

Mi consejo es que escriba el código como si el sistema operativo no lo ayudara, ya que eso es lo que le dará más opciones para mejorar el software en el futuro.