realmente no se desasignan... simplemente el SO marca ese espacio como "usable" y si otro programa entra, sobreescribe ese valor "basura" así como tu lo hiciste con el tuyo


ej, prueba este programa

#include <iostream>
using namespace std;
int main(){
int valor_con_basura;
int valor_limpio = 0;//aquí sobreescribes la basura
 
cout << "basura de la ram: " << valor_con_basura << endl;
cout << "valor limpio : " << valor_limpio << endl;
 
 
return 0;
}

por eso es importante siempre inicializar variables

malloc lo que hace es decirle al sistema operativo que le de más ram al programa (es decir, que la marque como "usada" para que nadie más la accese y darle el permiso a el programa)

cuando se cierra el programa, queda disponible

en general no... pero se hace dentro del tiempo del programa para que no se te acumule basura, ya que si declaras muchas veces una misma variable (ej en un ciclo), depende de la gestion del compilador cada instancia puede pedir más y más ram para no destruir las viejas (si tu no las destruiste tal vez es porque las accedes)

Yo tampoco es que sea un experto, pero el funcionamiento general (hasta lo que yo sé) de la memoria de un programa es el siguiente:

• Todo programa tiene una capacidad máxima de memoria (estática + dinámica) igual a la capacidad máxima de RAM. Por ejemplo, una arquitectura de 32 bits tiene puede tener como máximo 4 GB de RAM, y por tanto, esa es también la capacidad máxima de memoria de CADA programa. Para arquitecturas de 64 bits, pues el máximo (ésta vez teórico) de memoria sería de 16 Exabytes (debido a que 16 EB es una barbaridad, ningún sistema operativo soporta todavía tanta memoria; todavían van por el órden de soportar algunos terabytes). Si cada programa tiene 4GB de RAM como máximo, y tu ordenador puede tener 4 GB de RAM como máximo también, y tienes dos programas que juntos suman más de 4GB, ¿qué es lo que pasa? Pues que entra en juego la memoria virtual, que es memoria de disco duro que se utiliza para los programas. Eso lo hace el SO por tí; como programador, tú crees que tienes 4GB continuos de memoria RAM como máximo.
• Cada SO pone un límite máximo en la cantidad de memoria para variables locales (tamaño de la pila, o stack), que un programa puede tener. En mi SO (Linux 3.13), la pila no puede ser más grande que 8 MB. Es decir, si mi programa tuviese una única variable local, la más grande que podría tener sería: `char var[8388608]`, o dos vectores `double[524288]`. De todas formas, aquí se me escapan los detalles, pero sé que siempre hay cierto porcentaje de la pila que el compilador utiliza para sí mismo, así que la correspondencia "variables locales del programa"/"tamaño actual de la pila", es en realidad muy difícil de calcular.
• En cualquier momento del programa, la memoria dinámica (es decir, el llamado montículo o heap; la memoria que consigues con `malloc/new`) disponible es: la máxima del programa, menos la consumida actualmente por la pila, menos otros factores adicionales que también consumen espacio. Obviando ésto último por simplicidad, si tengo un máximo de 4GB de RAM (arquitectura de 32 bits), y la pila llena (si el máximo es de 8MB, como en mi caso), pues sobrarían 3GB y 1018MB para variables locales.
  

La diferencia entre la pila y el montículo, es que la pila funciona como una pila de platos, cada nueva variable local, se coloca justo encima en la memoria de la última variable local creada. Cuando termina una función, se descartan, quitándolos de la cima de la pila, todas las variables locales y parámetros de la función, de modo que la "nueva cima", era la misma que antes de que la función fuera llamada. Como bien dice "Engel Lex", la memoria no se borra, solo se "reutiliza" (una vez que la función termina, ese espacio vuelve a estar disponible).

Respecto al montículo también funciona como una pila de platos, pero un poco diferente; algo así como una pila fragmentada. En teoría (en realidad, cada SO puede tener sus propias políticas para manejar el montículo), cada vez que tú pides al SO un nuevo dato dinámico (`malloc`/`new`), él lo coloca encima del último dato dinámico creado. Si se borra un objeto dinámico (free/delete), se queda un hueco libre en medio de la pila (y reutilizable), pero el tope del montículo sigue siendo el mismo. Ésto se diferencia de la pila en que la pila funciona como un muelle que se estira y se encoje a medida que se llaman a nuevas funciones y éstas terminan, mientras que el montículo es una "pila fija", destruir un objeto nunca "encoje" el montículo, sino que deja huecos entre medio.

Cuando has solicitado tantos objetos que el montículo ha llegado a su tope, entonces cuando solicites un nuevo objeto dinámico al SO, éste empezará a buscar un hueco en medio del montículo lo suficientemente grande para dicha variable, y lo colocará ahí. Si no quedase un hueco lo suficientemente grande, la verdad es que no sé qué haría el sistema operativo (puede que reordene el montículo para juntar huecos y conseguir un hueco más grande --al igual que cuando desfragmentas un disco duro; lo que no creo, porque invalidaría los punteros; o puede que sencillamente te diga que no queda memoria, ¡aunque la suma de huecos sea lo suficientemente grande!).

Por último, hay que tener en cuenta que, como el montículo puede ser enorme, el SO te "virtualiza" el montículo para que lo veas como una pila contigua con huecos, cuando en realidad, cada "trozo" de montículo puede estar colocado en diferentes lugares de la RAM y memoria virtual (disco duro). Si has reservado memoria para un objeto, y éste se encuentra actualmente en disco y no en RAM, y quieres "utilizar" dicho objeto (acceder a un campo de él por ejemplo), el SO cogerá el "trozo" de memoria virtual (página), que contiene a tu objeto, y lo colocará en RAM, y posiblemente, cogerá un trozo de RAM que ahora mismo tu programa no esté utilizando, y lo enviará a disco como intercambio (aunque si hay suficiente RAM disponible, seguramente evitará ésto último). Así que el sistema operativo se encarga de mover las páginas de memoria virtual entre disco y RAM a medida que vas utilizando tus objetos dinámicos. Por ese motivo, aunque el montículo sea enorme y uno tenga la tentación de enviarlo todo allí, utilizar el montículo siempre es MUCHÍSIMO más lento que utilizar la pila.

Ahora, teniendo en cuenta todo ésto, ¿qué ocurre con el montículo (memoria dinámica) cuando el programa termina? Pues el SO mantiene un rastreo de toda la memoria dinámica que ha consumido el programa, y cuando éste termina, la elimina. Así que un programa finalizado no dejará memoria utilizada, ni en RAM, ni en memoria virtual.

Con la pila pasa lo mismo, y además con una ventaja. Como la pila nunca está en memoria virtual, y es como un bloque fijo en la RAM, solo hay que quitar dicho bloque de la RAM y listo. Eso no supone ningún problema para ningún SO, y no necesitan "rastrear" nada, con saber dónde empieza la pila y donde acaba es suficiente (y por éste motivo, los SOs restringen los tamaños de las pilas --compara 8MB de pila con 4 gigas de RAM; para que todas las pilas de todos los programas y del SO estén en RAM siempre).

De todas formas, aunque el SO libere toda la memoria de tu programa sin problemas, DEBES liberar toda memoria que hayas consumido en cuánto ya no la necesites. No solo para evitar el riesgo de que tu propio programa se quede sin memoria (lo cuál es muy raro, ya que con 32 bits tienes 4GB de RAM, y si tu arquitectura es de 64bits, pues mucho más), sino para evitar el riesgo de que tu "ordenador como un todo", se quede sin memoria mientras tu programa está aún en ejecución.

Date cuenta que, aunque cada programa tenga 4GB de RAM como máximo, tu programa podría ejecutarse en un ordenador con 2GB físicos de RAM (por que, por ejemplo, el dueño decidió no comprar otra tarjeta de memoria RAM adicional para completar los 4 GB). Además, la cantidad de memoria de disco que puede utilizar el SO también está limitado, y un usuario de tu programa puede tener configurado su sistema operativo para que la memoria virtual no consuma demasiado espacio en disco (el trozo de disco duro que el SO reserva para colocar páginas de memoria virtual se llama memoria de intercambio). Un motivo para hacer ésto, es que cuánto más pequeña sea la memoria de intercambio, más probable es que el SO coloque páginas de memoria virtual en RAM en vez de en disco (para evitar que la memoria virtual se llene), haciendo que todos los programas vayan más rápido.

Sea por lo que sea, SIEMPRE borra tu memoria dinámica en cuánto no la necesites. Si los programadores no liberaran nunca la memoria porque el SO hace el resto, en cuánto tuvieses 4 o 5 programas abiertos, más todos los servicios y demonios que se ejecutan en segundo plano, más el propio sistema operativo en sí, podrías quedarte sin memoria (a no ser que cierres una de las aplicaciones).