Alcune volte durante la programmazione definiamo o dichiariamo funzioni, definizioni, variabili, macro e strutture dati. ma non usare mai quelli dopo.I compilatori rimuovono funzioni non utilizzate, definizioni, variabili, macro, ecc.
Dipende:
macro vengono convertite in programma di testo dal compilatore. Loro non rappresentano altro che il testo che li sostituisce, e non vivono oltre il tempo di compilazione (a meno che ... vedi sotto).
Le variabili locali e tali sono probabilmente rimossi, se non hanno un costruttore o un distruttore non banale. (Non si vuole qualcosa come scoped_lock rimosso solo perché non si di riferimento in un secondo momento nel codice.) Lo stesso vale per le variabili e funzioni con collegamento interno (ad esempio definiti a namespace portata con la parola chiave static). Nella maggior parte dei casi, tuttavia, le risorse necessarie per tali oggetti sono minime e il risparmio minimo.
Le funzioni sono leggermente diverse e dipendono. Una funzione virtuale verrà generalmente considerata "utilizzata" se c'è sempre un'istanza di questo tipo e sarà quasi certamente presente, anche se non si chiama mai .
Oltre questo (e questo vale anche per le variabili globali): è fino al linker. La granularità della maggior parte dei linker è il file oggetto che risulta dalla compilazione di una "unità di traduzione": il file oggetto è o non è parte del programma. Se il numero di telefono indica al linker di incorporare il file oggetto, è necessario aggiungere a tutto ciò che è contenuto. Se si inserisce il file oggetto nella libreria (statica) e si indica al linker di utilizzarlo, il programma di collegamento incorporerà il file oggetto nel programma if e solo se risolve un esterno non risolto altrimenti. Ma se lo incorpora il file oggetto, in genere incorpora tutto lo di esso. (Qualsiasi buona libreria metterà ciascuna funzione non virtuale in un file oggetto separato, in modo da non ottenere più del necessario.)
A questo proposito, le DLL si comportano come file oggetto (nonostante il loro nome ). Se si collegano i file oggetto in una DLL, il programma che lo utilizza otterrà tutta la DLL o nessuno.
Infine: sebbene non faccia parte del programma, i file oggetto e l'eseguibile finale conterranno spesso informazioni simboliche; i migliori sistemi manterranno anche le informazioni relative ai macro , in modo che il debugger possa visualizzare le cose nel modo in cui le ha scritte . (Quanto può fare a che fare con le macro è discutibile.)
Se il compilatore o il linker può vedere che non ci sono riferimenti a funzioni C o variabili C, possono (e di solito fanno) rimuovere quelle cose inutilizzate.
Le definizioni di macro inutilizzate non si inseriscono affatto nel codice compilato. E lo stesso vale per typedef e simili.
È tuttavia più difficile rimuovere codice inutilizzato e dati implementati nelle parti di assieme dei programmi.
E non è sempre ovvio al compilatore se qualche variabile referenziata o qualche codice verrà mai usato o eseguito.
Quindi, sì, in questi giorni, la maggior parte delle cose chiaramente inutilizzate viene rimossa.
Dipende dalle cose inutilizzate. Qualsiasi cosa a livello globale (e che include la maggior parte delle funzioni) può essere rimossa dal linker e la granularità della maggior parte dei linker è il file oggetto, quindi non appena il file oggetto viene incorporato nel programma, si ottiene tutto ciò che è in esso . In genere, tutto ciò che verrà rimosso sono le variabili locali e così via; cose che non richiedono molte risorse comunque. –
@JamesKanze Ho menzionato i linker. La granularità non deve essere un singolo file oggetto (unità di traduzione). –
Non deve essere, ma lo è quasi sempre. In pratica, c'è un motivo per cui i programmatori esperti tendono a mettere ciascuna funzione in un file sorgente separato durante la costruzione del codice della libreria. –
GCC genera sempre avvisi di variabile inutilizzati con '-Wall', quindi immagino di sì. I macro – Blender
sono irrilevanti, ma vedi http://stackoverflow.com/q/6215782/390913 – perreal