2010-08-31 16 views
7

He estado jugando con la incrustación de recursos en mi programa C++. Con el fin de hacer esto Hexdump los datos a una matriz simple, es decir¿Liberación de memoria estática? no, eso no puede ser correcto

unsigned char image_png[] ={ 
    0x0a, 0x0b, 0x0c, 0x0d, ... 
}; 

Algunos de estos recursos no se utilizan después de la carga (es decir, que se convierten a otra cosa y luego los datos originales es sólo mayor ... aunque un poco de volumen para la facilidad de distribución podría valer la pena).

Tengo curiosidad por saber si hay una forma de insertar el recurso en el programa, para que no tenga que preocuparme de que el binario pueda encontrar todos sus recursos más importantes, pero luego libérelo una vez que lo haya hecho se usa para que la huella de memoria de tiempo de ejecución tenga un impacto menor.

¿Esto es posible? Si es posible, ¿es algo estúpido tratar de hacer? Por ejemplo, tal vez el sistema operativo mantendrá toda la imagen del programa en la memoria de todos modos (no estoy seguro exactamente cómo funciona).

edición: Para responder a los comentarios, estoy trabajando en Linux (Ubuntu 10.04), pero si hay soluciones multiplataforma me gustaría oírlos

+1

pregunta interesante! – Milan

+0

Saber en qué sistema operativo está trabajando permitiría mejores respuestas. – Novelocrat

+3

Normalmente, el O/S no mantiene todos los ejecutables en la memoria física. Cuando intenta acceder a una parte de su programa por primera vez, se activa un error de página y esa parte se carga desde el disco duro. Si no lo usa durante un tiempo, se eliminará de la memoria física. Intentar acceder de nuevo dará como resultado otro error de página (editar: una falla de página no es nada de qué preocuparse, es como una falla de caché) – Tomaka17

Respuesta

4

Como Tomaka17 dice, realmente no tienes que preocuparte por ello; si nunca tocas ese recurso, nunca aparecerá una falla y no consumirá memoria física. Cuando carga una DLL/tan/lo que sea, realmente solo mapea el archivo en la memoria; intentar acceder a ese archivo es lo que hace que realmente se lea el archivo, pieza por pieza.

+0

así que definitivamente usaré el recurso * una vez *, al comienzo del programa. es decir, cargue un archivo png, conviértalo en un mapa de bits nativo para mostrar en la GUI. Después de eso, el png ya no es necesario. – cheshirekow

+0

Esto no es estrictamente cierto, porque con toda probabilidad los datos estarán en la misma página de memoria que otros elementos que * usa *. –

+0

@Billy Concedido, pero las imágenes son bastante grandes, y las páginas son solo 4k. Es mucho mejor que la vista ingenua de la DLL completa cargada al pie de la letra –

0

Una forma que he visto que se utiliza en varios las aplicaciones concatenan los datos al final del ejecutable y luego añaden el tamaño de los datos.

Puede abrir el archivo ejecutable, ir al final de la secuencia y leer el tamaño de los datos, luego retroceder ese tamaño y leer los recursos.

Tenga en cuenta que los recursos serán exactamente como los puso, por lo que la organización podría estar en riesgo.

Tampoco puedo decir si esta es una buena práctica, pero parece que funciona.

+0

Esa es una solución inteligente. Podría analizar los recursos en conjunto y luego usar una biblioteca tar para encontrar todos los archivos dentro del archivo. Si entiendo correctamente, el proceso será algo así como: $ SIZE = stat -s% o "ejecutable"; cat resources.tar >> ejecutable; printf "% 20i" $ SIZE >> ejecutable; – cheshirekow

+0

Solo prepárese para que todos los antivirus bajo el sol comiencen a quejarse cuando las sumas de comprobación no coinciden. ;) –

+0

Buen punto. En una nota lateral, un programa grande que consume una gran parte de los recursos del sistema, ralentiza (y adivina) todo lo que haces, y de forma esporádica impide el funcionamiento normal de un sistema ... me suena como un virus. Mi software antivirus favorito: rdiff-backup. – cheshirekow

Cuestiones relacionadas