[QGHG-it-dev-list] Opšta pitanja
Nenad Korolija
nenadko at gmail.com
Mon Mar 14 01:34:28 CET 2022
Bas tako. Procedura je poprilicno opsta ne vezuje se samo za C++, a kamoli
za kompajler.
Problem nastaje ako se neko uhvati npr. za color.cpp i hoce bas njega prvog
da kompajlira, bez da gleda ostatak sveta i lakse mu je da vice na sav
glas, nego da vidi sta se desava unaokolo i da ima pri ruci sve sto mu
treba...
Uloga hpp fajlova mu je da kad kompajlira npr. color.cpp, trazi da
color.hpp includuje sve hpp-ove koje color.cpp koristi.
Inace, nisam razumeo poslednje pitanje "kako VS povezuje imena u .hpp
fajlovima".
Pozdrav,
Nenad
On Sun, Mar 13, 2022 at 4:41 PM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>
> 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
> >
> >
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220314/68bce72d/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list