[QGHG-it-dev-list] Opšta pitanja

Marko Vojinovic vmarko at ipb.ac.rs
Sun Mar 13 05:14:10 CET 2022 

Vidi ovako --- triangulator.hpp je "glavni" .hpp fajl, u koji su include-ovani
svi ostali .hpp fajlovi. To znaci da postupak kompajliranja ide otprilike ovako:

(1) Kad preprocesor naidje na direktivu #include "triangulator.hpp" u bilo kom
.cpp fajlu (dakle odmah na pocetku), on na to mesto prosto copy-paste-uje ceo
taj fajl, kao sto je Nenad objasnio. Onda nastavlja da procesira taj sadrzaj, i
na slican nacin copy-paste-uje sve ostale .hpp fajlove koji su bili
include-ovani u triangulator.hpp.

(2) Kad preprocesor zavrsi sa svim tim copy-paste-ovanjem, i kad obavi sve
ostalo sto inace obavlja, onda na scenu stupa prevodilac, koji (a) vidi sav
sadrzaj svega sto je include-ovano, i (b) koristi to da kompajlira dati .cpp
fajl u odgovarajuci object-fajl.

(3) Kad prevodilac zavrsi svoj posao, na scenu stupa linker, koji spoji sve
object-fajlove od svih kompajliranih .cpp fajlova, i tek on povezuje sva imena
sa definicijama f-ja (preprocesor i prevodilac to ne rade). I na kraju, kad
linker zavrsi svoj posao, dobijes izvrsni (.exe) fajl.

Ovaj ceo postupak je (koliko mi je poznato) opsta procedura za sve kompajlere,
ukljucujuci g++, VS, i bilo koji treci. Postupak tako slicno radi (grubo receno)
cak i za druge programske jezike (koji se kompajliraju, interpreteri su prica za
sebe), tako da nije ovo nista specificno za C/C++/isl. Ovako se generalno prave
svi izvrsni fajlovi, u kom god jeziku da su pisani i kojim god kompajlerom ih
pravio, na kom god operativnom sistemu i hardveru.

E sad, ja naravno ne znam *sve detalje* kako to tacno radi VS (ne znam zapravo
ni sve detalje kako to radi g++, nisam nikad citao uputstvo do tih detalja...),
ali okreni-obrni VS mora nekako da prodje kroz korake (1,2,3), nema tu nikakve
narocite magije. :-)

Nisam siguran da li je ovo odgovorilo na tvoje pitanje. Ako imas jos nesto sto
te zbunjuje, javi. ;-)

:-)
Marko


Dr. Marko Vojinovic
Group for Gravitation, Particles and Fields
Institute of Physics
University of Belgrade
======================
home page: www.markovojinovic.com
e-mail:    vmarko at ipb.ac.rs



On Fri, 11 Mar 2022, Dusan Cvijetic wrote:

> Pozdrav,
> 
> Dosta ste mi rasvetlili funkcionisanje programa, ali imam još jedno pitanje:
> da li builder prolazi samo kroz .cpp fajlove, ili mu i .hpp fajlovi igraju
> ulogu? Pošto je triangulator.hpp
> uključen u .cpp fajlove, a ne u .hpp fajlove, kako VS povezuje imena u .hpp
> fajlovima?
> 
> Pozdravi,
> Dušan
> 
> сре, 9. мар 2022. у 08:22 Nenad Korolija <nenadko at gmail.com> је написао/ла:
>       Zdravo,
> 
> Ne secam se da li sam vec objasnio VS problem, tj. moje vidjenje istog i kako
> bi trebalo pod linux-om da se kompajlira poveci projekat.
> 
> Recenica prof. Milićeva je tacna, ako se uradi sledece, sto Dušanu i
> savetujem:
> Gde god da se nadje #include "pera.abc", mozes da se copy paste-uje sadrzaj
> fajla pera.abc umesto te include direktive.
> Dušane, ako to uradis za prvu verziju softvera koja ti nije radila
> (jednostavnija je, ima manje fajlova, nema biblioteke), videces da ces dobiti
> jedan veliki main.cpp i tada se
> stvarno u jednom fajlu nalazi sve sto ti treba. Takav fajl bi trebalo da mozes
> da kompajliras i u VS.
> Mislim da je problem VS to sto pokusava nezavisno da kompajlira neki tamo cpp
> fajl, pa kuka ako mu nesto fali.
> U sustini, dobro bi i za Linux bilo da imamo Makefile koji kompajlira
> nezavisno fajlove, pa na kraju linkuje. Taj deo smo za pocetak preskocili,
> pogotovo imajuci u vidu da ne
> koriste svi Linux. Da bi mogao svaki fajl da se kompajlira nezavisno, bilo bi
> potrebno da svaki include-uje hpp sa deklaracijama koje mu trebaju.
> 
> Pozdrav,
> Nenad
> 
> On Wed, Mar 9, 2022 at 12:33 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>
>       Pozdrav Dusane,
>
>       Nisam do kraja siguran sta te tacno zbunjuje, i verovatno ce Nenad i
> Jaroslav moci da ti odgovore pametnije od mene, ali evo da probam...
>
>       Prvo --- obrati paznju da na pocetku *svakog* .cpp fajla (a ne samo
> main.cpp fajla!!) include-ujemo ceo triangulator.hpp fajl, koji u sebe
> include-uje sve ostale .hpp
>       fajlove. To znaci da preprocesor dobije deklaracije *svih* klasa i
> *svih* f-ja kroz triangulator.hpp (sve je forward-deklarisano u .hpp
> fajlovima), pre nego sto stigne
>       do bilo kog parceta koda koje zapravo treba kompajlirati. Tako da (nakon
> preprocesora) kompajler tj. prevodilac ima sve simbole i sva imena vec
> definisana kad pocne da
>       radi na bilo kom .cpp fajlu. Tako da nema za sta da prijavi gresku, ni
> za jedan od .cpp fajlova koji kompajlira.
>
>       Drugo --- treba da ti bude jasan dizajn naseg koda. Mi pravimo nesto sto
> se zove "static library", biblioteka rutina koju korisnik treba da linkuje sa
> svojim main.cpp
>       fajlom u nekom svom kodu, i da poziva gotove f-je koje smo mi napravili.
> Nas main.cpp radi upravo tako, i sluzi nam za testiranje f-ja biblioteke. Sam
> main.cpp naravno
>       nije deo biblioteke, ali svi ostali .hpp i .cpp fajlovi jesu.
>
>       Biblioteke rutina su potpuno normalna i standardna stvar, i vec ih
> koristis u svakodnevnom programiranju --- na primer, kada treba nesto da
> izracunas pomocu
>       trigonometrijskih f-ja ili sl. u svom C++ kodu, ti include-ujes math.h
> header (ili kako se vec zove) u svoj main.cpp. I onda, nakon kompajliranja
> tvog fajla, linker
>       automatski ulinkuje u tvoj izvrsni fajl i biblioteku math-library.a
> (verovatno se zove drugacije, i nije staticka nego neki .dll ili stagod), u
> kojoj se nalaze
>       prekompajlirani object-fajlovi koji sadrze implementacije za sinus,
> kosinus, isl --- tebi je dovoljno samo da ih pozoves u svom main.cpp kodu, jer
> ih je neko drugi vec
>       implementirao i spakovao u biblioteku. Neki zamisljeni krajnji korisnik
> dakle treba da upotrebljava nasu biblioteku rutina na *potpuno isti* nacin kao
> sto upotrebljava
>       math.h, string.h, stagod.h...
>
>       Detalji i objasnjenja sta su biblioteke rutina (static, shared i dynamic
> tipovi), kako rade i cemu sluze, mozes da procitas u Program Library HOWTO
> [1], ako te zanima.
>       HOWTO je pisan za Linux, ali sustina i koncepti su isti i za Windows
> (mozda se samo drugacije zovu, .dll ili vec kako). U svakom slucaju, rezime je
> da je staticka
>       biblioteka prosto jedna arhiva (poput .zip fajla) u koju je "zapakovana"
> gomila kompajliranih object-fajlova u jednu konzistentnu celinu. I onda, kada
> korisnik pise
>       svoj main.cpp fajl, on prosto moze da include-uje triangulator.hpp (cime
> za preprocesor i kompajler obezbedi forward-deklaracije svih imena i simbola),
> zatim
>       kompajlira svoj main.cpp (koji koristi te f-je i simbole), i na kraju u
> njega ulinkuje nasu biblioteku (triangulator-library.a), cime dobije izvrsni
> (executable) fajl.
>       I to je sve.
>
>       Nas main.cpp fajl to vec sada tako radi (mozes da pogledas
> build-script.sh da vidis kako g++ pravi biblioteku i kako je ulinkuje sa
> main.cpp-om...), ali prvi
>       "ozbiljan" primer upotrebe nase biblioteke ce da bude GUI (koji je
> Jaroslav poceo da pravi) --- to ce na kraju da bude jedan izvrsni fajl, koji
> ce da otvara prozore po
>       ekranu i da pise i crta po njima, i usput ce da poziva i izvrsava f-je
> iz nase biblioteke rutina. Jaroslav ce u main.cpp za GUI da include-uje
> triangulator.hpp, da
>       poziva po potrebi sve f-je iz nase biblioteke (kako mu koja gde treba),
> i onda ce tokom kompajliranja GUI koda da ulinkuje triangulator-library.a
> biblioteku (koja je
>       po pretpostavci vec ranije napravljena), cime ce dobiti izvrsni fajl
> "triangulator-gui.exe". Naravno, moguce je i potrpati zajedno sav kod (i za
> biblioteku i za GUI)
>       na jedno mesto i kompajlirati sve odjednom. Ali inteligentnije je da
> imamo dizajn tako da biblioteka rutina bude konceptualno odvojena od GUI-ja.
> Tako bismo omogucili
>       nekom tre
>        cem korisniku da upotrebljava nase f-je u nekom svom izvrsnom programu,
> a ne iskljucivo kroz nas GUI ili sl.
>
>       I na kraju --- ne znam kako Visual Studio tretira ceo kod, sta sa cime
> linkuje itd., ali mozes u build-script.sh da vidis kako to radi g++, i sta je
> cilj.
>       Pretpostavljam da VS moze da se podesi da sve nase .cpp fajlove spakuje
> u jednu biblioteku triangulator-library.dll, koju ce onda moci da ulinkuje
> prilikom
>       kompajliranja main.cpp fajla i da dobije .exe fajl. VS verovatno nesto
> slicno radi vec i sada, samo mozda ne pravi taj .dll fajl nego odmah sve
> object-fajlove (od
>       svakog naseg pojedinacnog .cpp fajla) na kraju zajedno ulinkuje sa
> main.cpp u izvrsni fajl. Za sada jos uvek nije vazno kako on to tacno izvodi
> --- kreiranje .dll
>       fajla cemo da rascistimo i organizujemo sve kako treba kad budemo
> napravili Makefile za ceo projekt, zasad jos mozemo bez toga.
>
>       Ok, nadam se da cela ova prica baca malo vise svetla na zamisao i
> organizaciju celog koda. ;-)
>
>       :-)
>       Marko
>
>       [1] https://tldp.org/HOWTO/Program-Library-HOWTO/index.html
> 
>
>       Dr. Marko Vojinovic
>       Group for Gravitation, Particles and Fields
>       Institute of Physics
>       University of Belgrade
>       ======================
>       home page: www.markovojinovic.com
>       e-mail:    vmarko at ipb.ac.rs
> 
> 
>
>       On Tue, 8 Mar 2022, Dusan Cvijetic wrote:
>
>       > Pozdrav,
>       >
>       > Otvaram ovaj thread jer mi se čini da bi bilo dobro da imamo sva
> pitanja koja nisu vezana za neki konkretan zadatak na jednom mestu.
>       >
>       > Ako se sećate, u početku sam imao problem što kod nije mogao da se
> prevodi u Visual Studio-u, dok je sasvim dobro radio sa gcc. To je u
> međuvremenu razrešeno, ali
>       sada mi uopšte nije
>       > jasno kako se kod za triangulator bilo gde prevodi.
>       >
>       > Koliko mi je poznato, prevođenje se vrši iz tri faze: pretprocesor
> vrši leksičku obradu, zatim se izdvajaju tokeni iz sirovog teksta, koje
> builder koristi da bi
>       kreirao .obj fajlove. Na
>       > kraju, linker prolazi kroz .obj fajlove i povezuje deklaracije sa
> definicjama, ukoliko se nisu nalazile u istom fajlu.
>       >
>       > Stil programiranja sa kojim sam se do sad susreo je nalagao da u .hpp
> fajl u kome koristim neko ime uključim .hpp fajl sa odgovarajućom
> deklaracijom. Tako bih,
>       recimo, morao da uključim
>       > colors.hpp direktno u classes.hpp, jer je jedno od polja KSimplex-a
> lista boja koje ga opisuju. Kada uključim colors.hpp na početku fajla, builder
> zna deklaraciju
>       klase Color i nema
>       > problema.
>       >
>       > Međutim, mi to ne radimo, već sve deklaracije uključujemo u
> triangulator.hpp, i zatim to dalje u main.cpp. Nije mi jasno kako builder
> "zna" deklaraciju klase Color
>       unutar fajla
>       > classes.hpp.
>       >
>       > U knjizi (Milićev, 1995, str. 71) sam našao:
>       >
>       >       Zbog potpuno nezavisnog prevođenja jednog fajla (prevodilac "ne
> vidi" ništa drugo osim onoga što se nalazi u fajlu koji trenutno prevodi),
> svaki programski
>       fajl treba da
>       >       sadrži sve što je potrebno za uspešno prevođenje tog fajla. To
> znači da je potrebno da u svakom fajlu postoje odgovarajuće deklaracije svih
> imena koja se u
>       fajlu koriste.
>       >       Svako korišćenje imena bez prethodne deklaracije u fajlu
> prevodilac prijavljuje kao grešku. /.../ Deklaracije imena navode se u svim
> fajlovima u kojima se ta
>       imena koriste.
>       >
>       >
>       > Prema gornjem teksu, očekivao bih da prevodilac baci grešku jer mu ime
> klase Color nije definisano. Ipak, nešto ranije na istoj strani, prof. Milićev
> je napisao i:
>       >
>       >       Prevodilac prevodi svaki programski fajl (skoro) potpuno
> nezavisno, ne znajući koji sve fajlovi čine program.
>       >
>       >
>       > Pretpostavio sam da rešenje moje nejasnoće leži u ovome (skoro), ali
> nisam uspeo na internetu da nađem nikakve detalje koji bi mi razjasnili kako
> radi prevodilac u
>       VS.
>       >
>       > Da li bi neko mogao da mi objasni zašto naš kod radi?
>       >
>       > Pozdravi,
>       > Dušan
>       >
>       > (1) Milićev, D, Objektno orijentisano programiranje na jeziku C++,
> Beograd, 1995.
>       >
>       >
>       >
>       >--
>       QGHG-it-dev-list mailing list
>       QGHG-it-dev-list at ipb.ac.rs
>       http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> 
> --
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list at ipb.ac.rs
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> 
>

More information about the QGHG-it-dev-list mailing list