Newsgroup: it.comp.lang.delphi
Titolo: Eliminazione codice in eccesso

Ciao a tutti.
Nelle unit collegate ad un progetto Delphi tramite le varie "Uses", è
compresa quasi sempre una buona percentuale di codice inutile ai fini di
quel particolare progetto. Mi riferisco a tutte quelle rutine, classi,
metodi, proprieta', ecc. che non vengono mai chiamate pur facenti parte
delle unit lincate. Cio' premesso, vi propongo i seguenti quesiti:
a) questo codice "superfluo" viene automaticamente ignorato dal
compilatore oppure contribuisce ad aumentare (inutilmente) le dimensioni
dell'eseguibile?
b) nel caso in cui non venga ignorato dal compilatore, mi piacerebbe
sapere se esiste in circolazione un tool (possibilmente gratuito) in
grado di eseguire in automatico questa operazione di pulizia prima o
dopo la compilazione.
Grazie.
Andrea Barbagallo

 dell'eseguibile?
Viene ignorato! Delphi porta nell'eseguibile esclusivamente il codice che 
viene utilizzato.
Alessandro Storniolo 

Andrea Barbagallo wrote:
Ti ho risposto( anche se a modo mio ) su DelphiEDintorni.
Ciao,
Andrea

Nell 'eseguibile vengono trasferiti solo quelle parte di codice che vengono
chiamati nel tuo progetto e dagli oggetti, dati, procedure, funzioni che
appartengono al tuo progetto e che tu indirettamente chiami anche
inconspevolmente.
es: ... se usi una classe tEdit devi usare per forza anche una classe
tControl per cui tutte e due le Unit che contemgono le due classi devono
essere presenti nelle uses.
Il collegamento delle parti viene eseguito dal _Linker_ che appunto (To
Link=colegare) collega le _chiamate_ del tuo progetto alle parti di codice
che si trovano nelle uses.
Perciò il Linker straferisce nell' eseguibile del tuo progetto solo quelle
parti di codice delle varie unit che sono dichiarate nelle uses che sono
necessarie per il tuo prgramma.
Se questo non avviene l' errore in generato è :
Unsatisfated external o qualcosa di simile.
Per verificare ciò è sufficente che fai una prova compilando un progetto nel
modo "naturale" e poi aggiungendo delle unit che non sono contenute nella
dichiarazione "naturale".
Le dimensioni del 2 files .EXE dovrebbe essere circa uguali se non
perfettamente uguali.
Ciao
Mario (
mari...@inwind.it
)
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 dell'eseguibile?
Tutte le unit inutili presenti nella clausola Uses che hanno del codice
nella sezione Initialization e/o Finalization fanno aumentare INUTILMENTE
la dimensione dell'eseguibile.
Esempio pratico:
1. Creare una nuova applicazione con la sola form principale;
   L'eseguibile con D7 è di 361 Kb
2. Aggiungere alla Uses la unit DBTables;
   L'eseguibile è di 608 Kb, nonostante non usiamo NULLA di questa unit.
Tutte le unit inutili presenti nella clausola Uses che inglobano delle
risorse esterne (dfm, res, etc; ad esempio con {$R *.dfm}) dichiarate SIA
nella sezione Inteface SIA nella Implementation fanno aumentare
INUTILMENTE la dimensione dell'eseguibile.
Esempio pratico:
1. Creare una nuova applicazione con la sola form principale;
   L'eseguibile con D7 è di 361 Kb
2. Aggiungere alla Uses la unit DBLogDlg;
   L'eseguibile è di 441 Kb, nonostante non usiamo NULLA di questa unit.
   Aprendo l'eseguibile con un editor esadecimale si noterà la presenza
   della stringa 'Database Login' che fa parte di DBLogDlg.dfm
   In questo caso l'eseguibile aumenta di un bel pò anche perchè DBLogDlg
   ha nella sua Uses la unit DB
Tutte le unit inutili presenti nella clausola Uses che hanno delle risorse
di tipo stringa dichiarate tramite "resourcestring" nella sezione Inteface
fanno aumentare INUTILMENTE la dimensione dell'eseguibile.
1. Creare una nuova applicazione con la sola form principale;
   L'eseguibile con D7 è di 361 Kb
2. Aggiungere alla Uses la unit SqlConst;
   L'eseguibile è di 363 Kb, nonostante non usiamo NULLA di questa unit.
   Anche qui con un editor esadecimale si noterà la presenza delle stringhe
   dichiarate in SqlConst.pas
Saluti,
Antonio
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Perň anche tu non scherzi con le ridondanze . :-)
Ti devi porre il problema di chi gestisce la form. Se invece compili una
consolle application hai bisogno solo di 39Kbyte.
Ciao
Mario - (
mari...@inwind.it
)


 Però anche tu non scherzi con le ridondanze . :-)
Si ho esagerato... Chiedo scusa a volte esagero col copia e incolla ;-)


 consolle application hai bisogno solo di 39Kbyte.
Andrea Barbagallo

Se compili la form vuota ti devi tirare dietro tutte queste unit.
Windows Messages SysUtils
Variants Classes Graphics
Controls Forms Dialogs
La gerarchia delle classi per la Form è :
tObject
tPersistent
tComponent
tControl
tWinControl
tScrollingWinControl
tCostumForm
e Finalmente tForm.
Se rimuovi anche una sola delle unit il programma non funziona perchè i
controlli che vengono eseguti da quella parte non sono presenti.
Tieni presente che ci sono parti di codice che semplicemente chiamano delle
API (application program inteface) di Windows ma se mancano il programa non
va e perciò è giusto che l'errore sia dato in compilazione.
Io non so, e non mi domando, dove sono tutti i controlli della mia form
ma so che: ad esempio (se ben ricordo) il tag ed il nome viene definito in
tComponent mentre la classe tObject esegue il 'create' ed il 'free'.
TPersistent controlla quello che è relativo agli Stream.
TControl e le altre che contengono la parola Control eseguono ciò che è
riferito ai controlli (per cui rettangoli) esempio Top Left Width ecc.
Inolttre gestiscono il Focus ed il Tab.
Per cui per avere un programma che _non fa nulla_ ma che comunque ha una
form che puoi muovere, ridimensionare, cambiare colore, cambiare il font in
uso devi occupare quella MEMORIA. (Oltre al fatto che la form deve poter
essere salvata e caricata in uno stream. E poi la form può ottenere e cedere
il focus ecc. )
E obbligatoriamente _Devi tirati dietro tutto quel codice_
E questo anche se esistono le DLL (Dinamic Link Library) perchè la chiamata
alla DLL deve essere fatta comunque. Ed inoltre la chiamata deve essere
interfacciata all uso che ne si fa al momento.
Se invece non ti poni il problema di avere una form, e vuoi eseguire
semplicemente un calcolo che visualizzerai in una finestra DOS (Quelle
nere). Utilizzerai la memoria di cui abbiamo parlato.
Stessa cosa se devi criptare o decriptare un testo. Non hai bisogno di avere
tutte la gestioni della form e perciò non ti porterai dietro tutte quelle
unit e perciò il tuo eseguibile sarà piccolissimo.
Si ritorna daccapo se vuoi il solo messaggio 'FATTO' in una ShowMessage per
cui alla gerarchia ed alla memoria
Spero di essere stato chiaro se non fatti sentire.
Ciao
Mario (
mari...@inwind.it
)


dopo la compilazione.
Dopo aver letto tutte le risposte date in questi giorni, mi chiedo come mai
oggi, nel 2004, ancora ci si pone il problema delle dimensioni
dell'eseguibile.
In tempi come questi dove si richiede mezzo miliardo di bytes di ram come
requisiti minimi a fronte dei 64 mila di un 486 di 10 anni fa.
E' vero che gli eseguibili di delphi sono "gonfiati" da inutili uses, e anche
io nel passato ho cercato un metodo per fare pulizia di queste, e alla fine ho
trovato un tools per D6 solo, ma non garantiva al 100% il funzionamento.
Alla fine, la verita' e' che puoi procedere *a mano* commentando ad una ad una
le uses tra parentesi graffe, e tentare di ricompilare.
Ma non so quanto conti questo, visto i numeri e le risorse con qui abbiamo a
che fare oggi visto che si parla in termini di mega, giga, ultra, ecc.... 
Ciao :-)
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

Grazie a tutti per i vostri contributi: siete stati chiari ed esaustivi.
Andrea Barbagallo

ICARUS 2 (freeware).
E' un analizzatore della uses list.
http://www.peganza.com/download.htm
Ciao,
-=SIMO=-