L'incorporamento di dati (come le immagini) in un file eseguibile sembra avere alcuni vantaggi, come una più facile distribuzione dell'eseguibile e una più facile compatibilità con diversi SO.
Ma è una buona pratica? Più in particolare, in che modo il sistema operativo gestisce un grande eseguibile? Utilizzerebbe molta più RAM del necessario?
Per incorporare i file di dati direttamente in un eseguibile, ci sono diverse cose da considerare.
Se i dati non sono necessari, saranno caricati? Se il tuo programma ha sempre bisogno dei dati, la risposta è "no". Inoltre, per la maggior parte dei SO il file eseguibile è mappato in memoria (dove le parti non vengono caricate fino a quando non vengono utilizzate), quindi la risposta potrebbe essere "no" in ogni caso. Se la risposta è "sì", incorporare i file di dati direttamente nell'eseguibile può aumentare il tempo di avvio e sprecare RAM.
I dati saranno necessari temporaneamente (ad esempio un'immagine che viene visualizzata solo all'avvio dell'applicazione)? In questo caso, vuoi liberare la memoria quando non ne hai più bisogno e può essere difficile / complicato liberare parte del file eseguibile.
C'è un limite di dimensioni del file eseguibile? Ad esempio, forse ha bisogno di lavorare su una sorta di sistema a 32 bit dove c'è un limite di dimensioni del file eseguibile di 2 GiB, e i dati che stai incorporando semplicemente non andranno bene.
Quanto bene lo gestiscono i tuoi strumenti? Per alcuni strumenti è estremamente facile inserire file binari arbitrari "come sono" in un file eseguibile o oggetto (ad esempio incbin di NASM o direttiva .incbin di GAS). Per altri strumenti può essere un problema al collo (ad esempio convertirlo in una matrice di byte che è possibile includere come codice sorgente solo in modo che il compilatore possa riconvertirlo in binario).
Quanto dovrebbe essere difficile per le persone modificare / modificare i dati? Questo può andare in entrambe le direzioni - forse vuoi rendere più semplice per gli altri membri del progetto (ad esempio artisti) modificare il file e incorporarlo è uno svantaggio; ma forse vuoi rendere difficile agli utenti finali modificare il file e incorporarlo è un vantaggio.
Quanto è difficile utilizzare effettivamente i dati incorporati? Per alcuni casi (ad es. Librerie che prevedono un nome file) l'incorporamento dei dati potrebbe causare un problema significativo.
Avrai una sorta di "auto-aggiornamento"? Se lo farai, sarebbe più efficiente avere più file più piccoli che possono essere aggiornati indipendentemente, piuttosto che un file di grandi dimensioni in cui non è possibile aggiornarne una parte e devi sostituire / aggiornare l'intero file.
Se intendi utilizzare Risorse , allora l'incorporamento di immagini e dati simili va bene. Sono caricati su richiesta, quindi il footprint della memoria non cambierà molto.
Si può anche finire per mettere questi dati in una DLL esterna, che ha un vantaggio: se è necessario inviare una nuova revisione del software ai computer dei propri clienti, non è necessario inviare la DLL che contiene le risorse , a meno che non siano cambiati anche.
Ricorda che le risorse vanno bene per icone o stringhe localizzate o immagini mostrate dalla tua app, ma ci possono essere modi più semplici per fare ciò che devi fare. Ad esempio, potrei usare Risorse per un gioco 2D che usa pochi sprite, ma non per memorizzare centinaia di trame per un grande videogioco 3D: o memorizzare le trame direttamente o in un contenitore ZIP 0% sarebbe un modo più flessibile di fallo.
Se intendi incorporare i dati direttamente nel codice sorgente in costanti, preferirò evitarlo principalmente per questi tre motivi:
Potrebbe non essere necessario che i dati siano disponibili direttamente. Se è memorizzato su disco, è possibile accedervi tramite uno stream. Se è una costante, sei costretto a prenderlo tutto in una volta.
Visualizzare e modificare i dati sarebbe un inferno. In generale, gli sviluppatori non hanno abilità per visualizzare (e modificare) le immagini attraverso le loro rappresentazioni binarie / esadecimali. Cosa succede se copi l'immagine con la costante sbagliata? Cosa succede se hai bisogno di cambiare l'immagine? La leggibilità (e la manutenibilità) del tuo codice soffre e tu non vuoi che.
Come archivi dati binari in un file di testo? La forma esadecimale sprecherà molto spazio. Anche Base64 ha un rapporto 4: 3. Inoltre, dovresti trovare (o scrivere) un convertitore.
e anche perché:
Potresti iniziare a ricevere strani problemi, come i problemi di codifica.
La compilazione può richiedere più memoria (a seconda della lingua, del framework e del compilatore),
I tempi di compilazione potrebbero essere influenzati (a seconda della lingua, del framework e del compilatore),
Il tempo di avvio e il footprint della memoria di runtime potrebbero essere influenzati, anche se non dovrebbe essere assunto, ma piuttosto misurato. Lingue diverse, framework e compilatori possono avere risultati diversi.
Leggi altre domande sui tag coding-standards data-structures