Kolega Obucina je u pravu, ali samo delimicno :)
Mislio sam da necemo ulaziti u tehnicke detalje, ali nemamo izbora. Dakle da krenemo od pocetka.
Uzecemo kao primer promenu kada brisemo TDBGrid i TDataSource.
Njihovim brisanjem sa forme ne dolazi do brisanja unit-a koji su dodati prilikom stavljanja pomenutih komponenti na formu. Zasto je to tako? Zato sto bi bilo vrlo nezgodno da se brise unit koji koristi jos neka komponenta na istoj formi, ili zato sto u kodu zelimo da kreiramo instancu neke klase uz pomoc FindClass() i njenog naziva (koji je string, da podsetim), a nigde drugde u projektu nemamo taj potrebni unit u uses delu kako bi usao u exe.
Da potkrepim primerom. Recimo da u direktorijumu sa projektom imamo jednu formu koja se zove MojaForma i njena klasa je TMojaForma. U pas fajl te forme dodajemo u initialization sekciju sledeci kod:
Code:
initialization
RegisterClass(TMojaForma);
end.
Na ovaj nacin globalno registrujemo klasu te forme.
Ova forma se ne nalazi u uses delu projekta, vec u uses unitu glavne forme. Na toj formi imamo dugme na koje kada kliknemo izvrsava sledeci kod:
Code:
var
MojaForma: TForm;
begin
Application.CreateForm(TFormClass(FindClass('TMojaForma')), MojaForma);
end;
Kada pokrenete program i kliknete na dugme sve ce raditi zato sto se MojaForma.pas nalazi u uses delu glavne forme i kompajler zbog toga prolazi kroz initialization sekciju fajla MojaForma.pas, i vidi liniju RegisterClass(TMojaForma) i zbog toga ukljucuje i tu formu u finalni exe. Iz glavnog unita mozemo da kreiramo tu formu bez obzira sto ne koristimo eksplicitno TMojaForma za kreiranje kao sto to uobicajeno radimo. Da nam okruzenje automatski odlucuje o tome, exe bi bio cak i kompajliran kada izbacimo MojaForma.pas iz uses dela, ali bi u toku rada program "pukao" jer ne bi nasao klasu koju trazimo. Znaci automatsko brisanje za sada nije opcija. Izmedju ostalog ta automatika sa dodavanjem nije deo kompajlera vec samog IDE okruzenja u kojem radimo.
Dalje, sada kada su ti uniti ostali neobrisani dolazimo u situaciju da kompajler ima unit DBCtrls i DB kao visak. Sta on radi? Initialization sekcija je "zivi" deo koda, znaci automatski ide u exe jer se radi o kodu koji inicijalizuje unit koji koristimo. DBCtrls ima na primer sledeci kod u init sekciji:
Code:
DB.DBScreen := TVCLScreenApplication.Create as IDBScreen;
DB.DBApplication := DB.DBScreen as IDBApplication;
Sto se tice kompajlera, nema razlike da li je neki unit borlandov ili se radi o nasem unitu. On kompajlira init sekciju, jer bi pretpostavke tog tipa bile realno neispravne. I naravno ako se u tom delu kreiraju instance neke klase, na primer, te klase ulaze u exe. Da li ih mi koristimo to nema veze, jednostavno init sekcija to znaci. Da li moze da se izbegne? Nekada da, nekada ne. U Borlandovom slucaju u nasem primeru sa DBGrid-om definitivno ne.
Plus, imamo i dodavanje resursa takodje u DBCtrls:
Code:
{$R DBCtrls.res}
plus jos neki resursi, sto se moze videti lepo iz MAP fajla:
Code:
c:\program files\borland\bds\4.0\lib\DBPWDlg.dfm
c:\program files\borland\bds\4.0\lib\DBLogDlg.dfm
c:\program files\borland\bds\4.0\lib\DBCtrls.res
Kompajler takodje ne moze da pogodi da li ce aplikacija ucitavati neke resurse ili ne. Iz jednostavnog razloga sto se i resursi ucitavaju uz pomoc njihovog naziva, koji je naravno obican string i koji moze cak da se definise u nekom ini fajlu koji ide uz program. Cak ni teorijski. Ako neko zeli da objasnim ovo, rado. U nasem slucaju je dodato oko 4KB u exe samo kroz resurse.
Sve je ovo moglo da se izbegne ako bi programer sam obrisao visak unit-a iz projekta. Tu dolazimo i do glavnog krivca za nas problem. Da, programer. Ni najbolje okruzenje na svetu, ni kompajler ne mogu pomoci u ovakvim situacijama. Ista situacija je ako programer postavi recimo quantum grid (koji nije vezan na neki set podataka) na neku formu u programu i zaboravi da je obrise, ukljucujuci i unite. Exe ce biti par MB veci, bez obzira sto niko realno nema koristi od tog grid-a.
Cela poenta je da kompajler radi svoj posao samo sto ima neka realna ogranicenja, koja mu ne dozvoljavaju da "pametuje". Tako da se ne radi o "verovanju", vec je u pitanju sta programer radi i kakvu percepciju rezultata ima na osnovu svog znanja.
Kolega Obucina je po meni, neka ne zameri, generalno u pravu, govoreci ovo na forumu, jer veci deo programerske populacije gleda na ovu stvar na osnovu skromnog ili nikakvog poznavanja internih mehanizama na kojima pociva cela Delphi magija (Ovde ne ubrajam kolegu Obucinu, ako bi neko lose pretpostavio). Lepota Delphi-a je sto im bez obzira na to daje velike mogucnosti u pogledu izrade aplikacija.
Pozdrav svima!